more visiting and less buffering in drawinglayer/

[Armin Le Grand]

Hi,

On 12/3/21 3:35 PM, Luboš Luňák wrote:
> On Friday 03 of December 2021, Thorsten Behrens wrote:
>> Luboš Luňák wrote:
>>> I've implemented a cache in the Skia backend to handle cases of
>>> drawinglayer being dumb and repeatedly asking to do expensive
>>> redraws of the same stuff over and over again, which requires that
>>> the underlying bitmap is the same object and not something created
>>> from scratch every time.
>> You meant to say application code being dumb & dropping their
>> ViewObjectContact instead of keeping it for the next paint? ;)
>  I don't understand in enough detail how all that stuff works, but I'd say 
> that the answer is that not always.
>From my POV it may then be feasible to get more knowledge of the
concepts behind that things, either by asking people who are still
available and did some of that stuff, or by reading more code, or by
checking the presentations held at various conferences which are
available and contain a lot of infos about the concepts. There is also a
lot of comments in the headers/sources explaining stuff e.g. for
Primitives and ViewObjectContact(s). This can of course always be
improved - there is no developer documentation (docu is the *cxx/*hxx
files we said with a blinking eye those days :-) - , but there are also
people here - a community.
>  I think application code is not involved 
> in tdf#104878, and even if, it's Impress, the app that AFAIK should be the 
> most adapted to drawinglayer&friends, so there is probably something wrong if 
> even that one can't get it right. And I definitely remember dumb things in 
> graphics stack code, a random example that comes to mind is Impress/canvas 
> having 0% hit rate for cached scaled bitmaps (with at leats two different 
> reasons for the caching being broken).

In this case it's - as you say - broken and thus an error. So please
talk about it, report it and fix it when it's an error - or motivate
others to fix it. I think it's not the most effective way if everyone
implements it's own buffers. This is possible (as we see), but I doubt
that it's effective - except that you do not need to cope too much with
the existing stuff ;-) It will even eventually conflict potentially in
the long run and wastes lots of energy :-( The ype of energy that is the
most valuable for the project - developer ressources.

Please note that there is nowadays type-template-based buffering of
system-dependent data - of *any* kind. That works for win/cairo/X11
specific bitmap representations. It also is used for buffering
system-dependent PolyPolygon path representations (cairo & win) which
are also expensive to re-create at each repaint. I see no hindrance to
use the same system for Skia. This is not complicated, just needs a
little research/looking (or asking & help) how it is used. It even can
have it's own 'decider' if it should be buffered longer or can be dismissed.

If there are cases for (software-)scaled/changed bitmaps for paint which
are not yet handled - and there are always such, of course - please
report them. This system can be used to do this, dependent of
attributes/necessities of your choice.

All the best,

Armin

--

ALG (PGP: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)