search

usrlocalben / pixeltoaster

Automatically exported from code.google.com/p/pixeltoaster
0 stars 0 forks source link

investigate ways to reduce buffer copies #4

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
win32 implementation copies from source buffer into surface, then copies that 
to vram - investigate 
lock/unlock approach allowing direct writing to 32bit (or floating point) 
buffer, providing optimized 
codepath when no conversion is required

Original issue reported on code.google.com by glenn.fi...@gmail.com on 1 Sep 2006 at 6:53

GoogleCodeExporter commented 8 years ago

Original comment by glenn.fi...@gmail.com on 2 Sep 2006 at 9:23

GoogleCodeExporter commented 8 years ago 
We could expose an internal buffer through the API.  There would be no 
guarantee that
an implementation would use such an internal buffer in all cases, and neither 
would
their be a guarantee about its format.

I see two ways we could do it.  Either expose lock/unlock functions and 
pitch/format
attributes through the main display API, or encapsulate it in an abstract Buffer
object that would use again use virtual pointers to different implementations.

What do you think?

Original comment by bram.deg...@gmail.com on 30 Jul 2007 at 1:51

GoogleCodeExporter commented 8 years ago 
enscaplate it

Original comment by jackjack...@gmail.com on 27 Jun 2008 at 7:39

GoogleCodeExporter commented 8 years ago 
If anyone is (still) curious about this, here is a rough draft for the win32 
version.

IMO, there's nothing to gain here unless conversion is needed and you would 
like to integrate some other operation into the conversion pipeline -- in my 
case, unswizzling tiled renderer output.

Original comment by benja...@rqdq.com on 6 Sep 2012 at 12:03

Attachments: