On Tue, 2003-01-21 at 09:42, Micah Dowty wrote: ... > The main reason this hasn't been done already is that there are a lot of issues > you have to worry about when writing directly to the framebuffer from an app: > > - How can the video driver get an application access to the framebuffer > in a relatively portable way? > > - When the widget is resized, you need to synchronize the app's drawing with > PicoGUI's drawing > > - If sprites are overlapping the area, what happens?
It is a rather specific situation. What Philippe explores is the possibilities for video playback and recording preview, to reach maximum possible perfs, at the cost of portability in the most extreme case. Also, in the specific case, no widget resize or sprite rendering shall occur. The codec application would want to directly access the FB mem. We believe it is the shortest path. If an API could exist to do this as cleanly as possible (remaining still quite specific, and the app having to care [and well behave] about a lot of things, such as FB mem bit format, resolution, clipping, etc.), that would be ideal. It can evolve to handle properly resizing and sprite blanking over the 'protected' area, but at first, it does not need. In the mean time, a quick+dirty hack /might/ be done. An appropriate plugin architecture can be designed in the future, but rather than designing now an architecture for not yet clearly specified requirements, at first the codec will probably be a separate program (the pragmatic way). Pascal ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
