Re: Plotter API
On Sun, 2009-06-28 at 16:27 +0100, Chris Young wrote:
On Sun, 28 Jun 2009 12:37:32 +0100, Michael Drake wrote:
> The existing plotter API has been slowly extended as NetSurf has
> evolved, and it's a bit inconsistent.
>
> John-Mark has put a proposal for improving it up here:
>
> http://wiki.netsurf-browser.org/plotter-api
>
> Comments welcome.
|All colours are in the form 0xAABBGGRR.
|On little-endian platforms, bitmaps are also 0xAABBGGRR.
|On big-endian platforms, bitmaps are 0xRRGGBBAA
If we're improving the plotters, can we get this fixed at the same
time? Colours should be in 0xRRGGBBAA on big-endian platforms, same
as the bitmaps.
I don't think so. If anything, the bitmaps should match colours. This
way, everything is 0xAABBGGRR on all platforms. I'm aware this component
ordering is rather odd -- it's a legacy thing from NetSurf's RISC OS
origins.
|bool (*find_font)(void *pw, const char **font_names, size_t n,
font_t *result);
Opening and closing fonts here is relatively slow, so I'd like to keep
it to a minimum. Can we assume that find_font should also open the
font in question?
If you want to, yes; it's entirely down to the frontend to make that
decision. The point of this API is to be able to map a CSS font-family
(be that a series of font names or a generic family) to some opaque
handle that identifies it to the plotter.
In many frontends, this will simply scan the provided list of font names
and pick the first that is present on the system.
Note, however, that this API doesn't provide you with information about
font weight, slantedness, or size. If you need that information to open
a font, then you may be stuck.
How do we find out when NetSurf has finished with it (for the page)?
It's guaranteed to be finished with it once the redraw has completed.
It's your choice whether to keep it around for longer.
Some way of keeping track of usage in the platform code and being
able
to flush any that have not been used for a while would be useful here
I think.
Can you not do this with the proposed API? An LRU cache of font
descriptors shouldn't be hard to implement on top of it. You'll want to
base usage on calls to the text plotter with the given font handle as
it's possible that the core redraw stuff will optimise out calling
find_font in cases where it already knows the font handle for some text.
Regarding generic families, the easiest thing would be for NetSurf
to
send the user's selected font for the desired family (from
option_font_sans etc) in the font_names array.
Yes, I'm inclined to agree. The array is sorted as per the original
font-family rule that generated it. For example:
font-family: "Helvetica", "Arial", sans-serif;
would produce an array:
Helvetica
Arial
<option_font_sans>
find_font need only scan as much of the array as needed to find a font
it can use.
J.