Plotter API

John-Mark Bell jmb at
Sun Jun 28 18:10:35 BST 2009

On Sun, 2009-06-28 at 18:00 +0100, Chris Young wrote:
> 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.

Ugh. Ok.

> > > 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.

I think it's unlikely that the core will cache that information across
redraws. In fact, it simply can't -- the reason find_font is a plotter
callback is that it depends on the output device, not the frontend.


More information about the netsurf-dev mailing list