Just to let everyone know where they are in the queue :)
Here's my current short-term todo list:
1. Write PGFX
2. Tomorrow (friday) night fix ez328 rotate bug
3. Re-test and fix ncursesinput
4. Make video drivers fast
Let me know if I forgot anybody, seems like many people have been submitting
bugs/feature requests lately.
--------- Rotate bug
About the rotate bug:
I'll take a look at that next time I have some time with my uCsimm box (my portable
power supply no longer works well)
In the mean time, try it with different combinations of bit depths, and try rotating
from the command line. Last time I tested ez328 with rotation it worked (and I took a
screenshot)
---------- PGFX (short for PicoGUI Graphics)
And, in case you're wondering what PGFX is...
This is my solution to the general evilness of low-level drawing operations in PicoGUI
and should be much relief to Oliver and Brandon's pgWriteCmd woes. pgWriteCmd is a
low-level interface I never really intended apps to use. PGFX implements what I had
planned all along.
The PGFX interface functions themselves are nice short primitives, that operate on a
pgcontext. The pgcontext contains a table of function pointers that implement the
primitives, and it contains information about the rendering device.
The app will obtain a pgcontext using a rendering-device-specific function, then
render to it without regard to what it actually is (well, mostly). I have started a
pgfx backend for the canvas widget. There will be an 'immediate' mode and a
'persistent' mode. The immediate mode will implement a more traditional drawing model
where each group of primitives is packaged, sent to the server, and rendered, but not
stored. The persistent mode would expose more of PicoGUI's gropnode manipulation
functionality and allow the server to do more work for the client, at the cost of some
complexity in the client.
When the bitmap-based primitives in pgserver are available, a pgfx backend will be
written for them allowing the app to easily switch rendering methods. (enable/disable
double-buffer for example)
Same will be true for any direct-to-framebuffer or SHM rendering implemented in the
future.
I would suggest anyone interested in the client-side graphics operations take a glance
through pgfx.h and make sure it's reasonable, because that's the API you'll be using :)
--
perl -e'socket S,2,1,tcp;connect S,pack(H16,"0200029a80692d32").\0x8;print
grep!/=/,<S>'
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/pgui-devel
