[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Benchmark: Brute force copy from GL pbuffer to image as data



On Sun, 26 Nov 2006 09:04:03 GMT "jose_ogp@juno.com" <jose_ogp@juno.com>
babbled:

> 
> > > 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 ....???

indeed. but look at it this way. it's like poring water into a large pool with
a firehose then trying to suck it back out with a straw. that's pretty much how
write/internal gfx card performance vs. reading back from the video card works.

the only time it's worth it is if your rendering is so complex that the cost of
the read-back (plus rendering in hw) is less than the cost of doing it in
software with the cpu. :)

the general view is "just don't do it - full stop". send your data one-way to
the gfx card and leave it there for display :)

> 	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.

sure - but if you are now down to like 5fps... which is quite likely - if even
that much... is it even usable at all?

> 	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 :)

i think that write then read-back just isn't going  to ever cut it - for
display. we need (as i brought up in the other thread) the ability to render
directly to an evas engine native surface :)

>    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
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
裸好多
Tokyo, Japan (東京 日本)