> > Would anybody be surprised if I said that it really isn't fast...
> > ahem. Just had to try. Pseudo code of a main loop:
>
> I'd tell you "why did you even try? I could have told you that!" :)
> It's not a sane path to go down. reading pixels back from the video
> card is simply death-asking for pain. the rule to follow here is
> "DON'T DO IT"
There are times when you may be limited to having to do
something like that for lack of a better solution.. eg. say that
you wanted to draw 3D objects of some sort, and you want to put
this on an argb32 since you want to use the results for ....???
Unless you have some fast 3D-rendering software routines,
you may just have to go with rendering via eg. OpenGl, to a texture
or pbuffer say, and then grab the pixels to your argb mem buffer.
Even if ultimately some version of the results do end up
on a display, it is possible that one may still have to go thru
this kind of indirectness for some reason or other (for example,
an evas image loader that would load some 3D scene format.. one
can imagine other situations as well).
If so, then it'd be a good idea to establish such a rendering
mechanism/path.. just in case it's needed :)
jose.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
