nanogui: Proposition: New functionality for psd->DrawArea
Subject:
Proposition: New functionality for psd->DrawArea
From:
Morten Rolland ####@####.####
Date:
12 Jan 2000 12:55:27 -0000
Message-Id: <387C84BD.610B033D@screenmedia.no>
Hello,
Looking through the code for GdArea and GdDrawImage, I figured
it might be a good idea to add some more functionality to
improve speed when clipping has to be performed (or rather,
plan ahead and prepare for optimized drivers that could
help us with clipping).
Today, when the entire area is visible, the psd->DrawArea
could be used (when implemented):
psd->DrawArea(psd, x, y, width, height, pixels);
If clipping is needed, it would be nice to use psd->DrawArea
to paint only parts of the image, e.g.:
psd->DrawArea(psd, x, y, width, height, pixels,
src_width, src_x, src_y);
The extra args would make it possible to extract a
small part of the image/area and paint only that. This
may require a change in the way clipping is handled, I'm not
familiar with the clipping code - but in order to be able to
go fast, I can't see a way around this functionality.
It may be better with a separate function call to do this.
On a side note; it seems to me there is a thin layer of
indirection in 'fb.c': The psd handle has a pointer to
FB_drawpixel() which only contains a single function
call to fbprocs->drawpixel in the framebuffer code.
Can this be avoided? Couldn't the 'linearXX_init' functions
just fill in the function pointers for all the functions
they support directly into the psd handle?
Before the linearXX_init functions are called, a set of
default functions can be initialized for the complex
driver operations that only uses the drawing primitives
guaranteed to be available to do its work. This way
not all drivers have to support all drawing operations.
The reason why I started to look into this is a desire to
exrtend the framebuffer code to support Area (Surprise!:-)
- Morten
