Re: Image loading and caching

Am 05.07.2016 um 22:31 schrieb Bryce Harrington:

>> OTOH, it might be worth implementing that in a generic way,
>> maybe even in cairo or some cairo-extension library.
>>
>> What's your opponion on that ?
>
> Caching buffers is a classic cat skinning problem.  :-)
>
> If the code can sit atop Cairo (i.e. exclusively use Cairo's public
> API), then having it be a separate library would be best.

That's the way I use this "ImageList-like Surface-Caching"
in my Widget-Toolkit, which is centered around a separate
library (a COM-wrapper around the cairo-FlatAPI).

There I store (COM-Object-wrapped) cairo-"resource-surfaces"
(which can come from PNGs, ICOs, JPGs and SVGs) in a HashList,
behind String-Keys (once, at resource-loading time, when the
App-Process starts up).

A "BaseWidget"-Object then sports an ImageKey-Property of type String
(instead of Type 'cairo-surface'), which might - or might not be set,
but when used, being more lightweight than a separate Mem-Allocation
in a dedicated Surface for each Widget... most of the image- and icon-
resources in an App are shared ones (and im my approach, they will then
be rendered "by String-Key" into ToolBars - or into Buttons, etc...)

The (Hash)ImageList-implementation is offering these resource-surfaces
process-wide, when the right string-key is used to retrieve them -
and there's a "RenderFromSurface"-method in the CairoContext-Class,
which accepts either a real Surface-ObjectInstance in the appropriate
Param-Position, or alternatively a StringKey which points into that 
global ImageList.

Also when Widget-Hierarchies are serialized (to JSON or XML), such a
Resource-StringKey is easily saved along with other Widget-properties
(as e.g. its Dimensions, BackColor, CaptionText etc.)

The only thing which has to be ensured, when such a saved Widget-
Hierarchy is later on "reloaded and sited", is that the global
ImageList was filled beforehand, the "shared surface-instances" in
place already, waiting for their "rendering-requests per String-Key"...

> Also, would be good to know if it could apply to use cases beyond
> widget toolkits.

One usecase I see, would be related to e.g. repeated Surface-renderings
into PDF-Pages (e.g. always the same Logo on each page) - but I'm aware,
that there's already the MIME-type related cairo-APIs, which try to
cover that...

Maybe an "official implementation" of such a "cairo-Surface-Cache"
could re-use these already existing Mime-APIs somehow... (using
the ..., char *data, ... parameter as the String-Key under which they
are reachable by a generic rendering-function, which accepts this
'char-data-key' as a valid replacement to a "real surface-pointer".

Olaf




-- 
cairo mailing list
[email protected]
https://lists.cairographics.org/mailman/listinfo/cairo