266 | | A possible solution to avoid function call overhead while allowing the raster functions to set single pixel values could be for the renderers to expose an inlined setPixel (and getPixel?) function, probably without any bounds checking for performance. for example |
267 | | {{{ |
268 | | #!c |
269 | | inline void setPixelAGG(imageObj *im, int x, int y, int r, int g, int b, int a) { |
270 | | im->buffer[x][y]=AGGPixelMacro(r,g,b,a); |
271 | | } |
272 | | }}} |
273 | | and then use a vtable approach to connect that to a generic setPixel function. |
274 | | |
275 | | '''update''': this won't work out as an inline function is of no use if we're using function pointers (i.e. the vtable) |
276 | | |
277 | | |
278 | | |
| 266 | The raster handling code will be updated to support a 32 bit plain RGBA buffer (in addition to GD's internal buffer format) |
| 267 | |
| 268 | |
| 269 | |
| 270 | The renderers that internally use a pixel buffer will present an interface to export to this format, so the raster functions can directly write into it. |
| 271 | {{{ |
| 272 | #!c |
| 273 | struct pixelbuffer { |
| 274 | unsigned char *data; //the actual data (eventually private) |
| 275 | int pixelstep; //number of bytes per pixel |
| 276 | int rowstep; //number of bytes per line |
| 277 | unsigned char *r,*g,*b,*a; //pointers to each component of the first pixel |
| 278 | } |
| 279 | }}} |
| 280 | |
| 281 | The renderers that don't use a pixel buffer (namely pdf and svg), will present an interface to merge a newly created RGBA buffer in this format. |
| 282 | |