discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Art backend Was: Package building


From: Fred Kiefer
Subject: Re: Art backend Was: Package building
Date: Sun, 8 Dec 2019 09:12:07 +0100


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

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]