Re: Plotter API
On Sun, 28 Jun 2009 17:02:28 +0100, John-Mark Bell wrote:
> |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.
The odd ordering causes potential problems here, as most of the Amiga
graphics functions expect RGBA or ARGB (ARGB is more common). If
that's the option then I'd rather it was all left in the current crazy
dual-fashion.
> 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.
Yes, should be able to. If the core is guaranteed to forget what
find_fonts has allocated (ie. it won't reuse it on subsequent redraws
even if redrawing part of the same page), then there is no problem.
If the core will cache the result of find_fonts and use it in
subsequent redraws, the platform code will need to know when it has
finished with it.
That's really more what I was getting at.
Regards
Chris