#46 LibGGI X target depends on LibGII

open
nobody
libggi (22)
5
2012-12-12
2012-05-29
Jon Taylor
No

The current LibGGI X target depends on LibGII, which is A) broken by design (shouldn't be required to use eventing in a graphics library), and B) results in a problem where the LibGGI config (which doesn't look for LibGII) succeeds and the build itself fails. I guess that there is no way to share access to an underlying target instance/lock between GGI and GII - that is the only reason I can see for why Brian used events management in a LibGGI target.

A core rewrite is apparently needed, and it will be somewhat heavyweight, but unfortunately the current system is broken and I don't know how it could be fixed unless a common target pool which can be cleanly extended on a extension by extension basis is made. Basic access mux/lock stuff at least for most targets needs to be broken out into a separate sublib management unit, probably with a whole-comprehensive API and resource conversion exposure - the core target lib and helperlib set will need to be able to handle basically every abstraction the target can throw, not just events or drawing commands in the cases of LibGII and LibGGI (which in turn will have to throw a sub-comprehensive core to their extensions).

My first inclination would be to abstract away all the console-type functions into a LibConsole which would be able to "handle" both LibGGI and LibGII as extensions (another one which springs to mind is the original LibGWT design, which wrapped together LibGGI visuals and LibGGI events and thus was "off to the side" of both of them). LibConsole would probably take both "raw" eventing (pure uncooked events, probably a simple bytestream) and "raw" graphics (directbuffer-type mmap()ed framebuffers) in as abstractions, allowing LibGII (cooked and routed eventing) and LibGGI (async graphics buffering and accelerated out-of-band drawing commands) to cleanly extend a much more abstract basis.

Discussion

  • Jon Taylor
    Jon Taylor
    2012-12-12

    After thinking about this a bit more, I think that the generic target stuff should go into LibGG instead of libconsole as described above. This would be a much cleaner abstraction, as the basic LibGG would encapsulate a wrapped target generically and allow the higher level libraries like LibGGI and LibGII to bounce their target code and functions off of the LibGG generic targets.

     
  • Jon Taylor
    Jon Taylor
    2012-12-12

    • summary: LibGGI X target depends on LibGII: fix with basic LibConsole --> LibGGI X target depends on LibGII