Re: Art backend Was: Package building

[Sergii Stoian]

> On 8 Dec 2019, at 10:12, Fred Kiefer <fredkiefer@gmx.de> wrote:
> 
> 
> 
>> Am 08.12.2019 um 03:07 schrieb Sergii Stoian <stoyan255@gmail.com>:
>> 
>>> On 6 Dec 2019, at 17:31, Fred Kiefer <fredkiefer@gmx.de> wrote:
>>> 
>> 
>>> Could you please explain in more detail what is wrong with each specific 
>>> screen shot? I can see that some entries in the popup list are shortened. 
>>> What else is wrong?
>> 
>> Application menu (Workspace) lacks border at the right side. I placed app 
>> menu above the window to see absent menu border.
> 
> We look into this one next. Perhaps you could also pinpoint down the commit 
> that changed this.
> 
>>> The GNUstep guy release 0.25.0 was in June 2016 and the following 0.25.1 
>>> release almost a year later. There have been plenty of relevant changes in 
>>> the string drawing during that time. The most important probably was to 
>>> usage of cached glyph advancements, but also the change in the string 
>>> drawing cache handling you mention. Could you try to pin down the commit 
>>> that broke things for you?
>> 
>> I’ve tracked down to suspicious commit - 
>> 31cb9914d166defcad9862eaed09c28be359ccbe.
>> Before this commit everything looks fine.
> 
> OK, that was the clean up commit for NSStringDrawing you mentioned before. 
> 
>>> The art backend is no longer actively maintained. I understand that you and 
>>> Riccardo still prefer it. Here it would help if you could provide patches 
>>> to get it working again. I am not very familiar with the art text handling 
>>> code.
>> 
>> I suppose it’s not direct art problem. Perhaps art should be adopted to 
>> NSStringDrawing changed caching, I don’t know until I understand string 
>> drawing change. What was the idea of that rewrite? Commit message doesn’t 
>> explain why that change was made. For me, It doesn’t look as “cleanup”. 
>> That’s why I asked you as author of that change.
> 
> What I changed back then was to have the scratch item that gets used for the 
> current drawing to be of the same structure as the cached items. The scratch 
> item now even gets stored in the same array as the cached one, so the 
> initialisation is identical. This really simplified the code and helped me 
> understand it better to allow for further restructuring. Try to understand 
> the code before and after that change and you may see the difference. The 
> code is still complicated but at least the data structures are cleaner.

Thanks, now I understand your intention.

> I also switched to using explicit types, for example for boolean values. But 
> I may have made a mistake there. On line 501 (and again on line 674) I 
> replaced the value 1 with NO and this looks wrong. As this stands for using 
> screen fonts it would affect the art backend, being the one where we actually 
> support screen fonts. 
> I cannot remember what was the reasoning behind that change. The difference 
> between the actual drawing code and this bounds computation is that during 
> the drawing we have the transformation to the screen and are able to 
> determine whether this is close to identity, in which case we use screen 
> fonts. The bounds computation may happen at any time, so we don’t know if 
> screen fonts should be used. Maybe the art backend relies on these being used 
> anyway? You could give it a try and use YES here instead. The lines in the 
> current code are 513 and 606

That’s it, thank you! I’ve changed lines you’ve mentioned and problem gone. 
What’s the point to change YES to NO? Was it intentional (some cairo backend 
specifics)?
I’ll prepare PR once I setup environment and compile master branch to test 
changes.

Sergii