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