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.