On Sun, 15 Dec 2002, Brian S. Julin wrote: > vis->opdisplay->idleaccel should be loaded with your target's > accelerator idling funtion. > > When a mode is set, the target is supposed to set vis->needidleaccel > if it wants the stubs renderer to provide accelerator-friendly pixel > functions. When the stubs renderer is opened, it checks the field and > loads the pixel routines from pixel.c if there is no need for > accelerator idling (needidleaccel == 0), or from pixela.c if there is > a need (needidleaccel != 0).
Well, it seems pretty complete however to have such an interface available inside libggi. It seems to me that the idleaccel function will be pretty close to ggiFlush() however. Except that it is automatic and the application has no control over its usage. (This is both a drawback or an advantage depending on the state-of-mind of the application developer btw.) > A sublib that has the need for idling the accelerator should provide > at least hline, vline, box; e.g. it should not leave solid-fill > primitives to the generic renderers, because the generic libs only > contain "accelerator aware" versions of the single-pixel functions. OK. Does this include copy_box, cross_blit and the like? (These ones may be more difficult to implement fully in hardware.) > Now, that's the way it's *supposed* to work. The xf86dga target code > still in CVS is a good example of this. Thanks for the pointer. [...] > IMO what needs to be done is to have renderers included in the > ggiIndicateChange() callback facility, and when an accelerator is > loaded, the generic renderers will be able to swap the function > pointers appropriately. Interesting. What about the case of an application that wants to manage itself the synchronization between the accelerator and the mmio fb accesses? (Ie: it wants to drawing in one area of the screen using the engine and in another area with the CPU.) Note that such an application is potentially brain-damaged... (So feel free to forget about it.) > (BTW, This is just one of many symptoms of the dl system needing to be > taken one step further than it already goes. See the "dummyfunc" > hacks and such used in most extensions for another.) meta-protocol versus methods overloading - is it something like this? Anyway, that's probably a much broader topic. Thanks for your information. I'll try to implement ggiFlush() correctly first (in fact, I've done a sort of ggiFlushStart()...). BTW, what about decoupling ggiFlush() into its lower-level components (ggiFlushStart() and ggiFlushCommit())? Do you think it would be useful? Rodolphe
