Re: Art backend Was: Package building
On 08.12.19 14:57, Fred Kiefer wrote: Am 08.12.2019 um 13:40 schrieb Sergii Stoian : On 8 Dec 2019, at 10:12, Fred Kiefer wrote: Am 08.12.2019 um 03:07 schrieb Sergii Stoian : 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. As I wrote, I cannot remember whether I did that on purpose or not. Both is possible. Both values are wrong, in some sense as I explained. That is why I might have changed them. But it is more likely that I just made a mistake here. Otherwise I would have documented the „improvement“ :-( I've created a PR #36. It's plain simple revert NO to YES at lines you've mentioned. However, another problem exists at master branch. One of the effects is shown on my WorkspaceMenu+HelpPanel screenshot: selection of index item shifted vertically. This problem appeared on 0.25.1 branch before NO/YES change, but got fixed after change. It's not the case with master. I suppose something wrong with empty string height detection (LayoutManager?). I need to investigate further. Sergii
Re: Art backend Was: Package building
> Am 08.12.2019 um 13:40 schrieb Sergii Stoian : > >> On 8 Dec 2019, at 10:12, Fred Kiefer wrote: >> >>> Am 08.12.2019 um 03:07 schrieb Sergii Stoian : >>> >>> 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. As I wrote, I cannot remember whether I did that on purpose or not. Both is possible. Both values are wrong, in some sense as I explained. That is why I might have changed them. But it is more likely that I just made a mistake here. Otherwise I would have documented the „improvement“ :-(
Re: Art backend Was: Package building
> On 8 Dec 2019, at 10:12, Fred Kiefer wrote: > > > >> Am 08.12.2019 um 03:07 schrieb Sergii Stoian : >> >>> On 6 Dec 2019, at 17:31, Fred Kiefer 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
Re: Art backend Was: Package building
> Am 08.12.2019 um 03:07 schrieb Sergii Stoian : > >> On 6 Dec 2019, at 17:31, Fred Kiefer 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
Re: Art backend Was: Package building
Hi Fred, > On 6 Dec 2019, at 17:31, Fred Kiefer wrote: > > HI Sergii, > >> Am 03.12.2019 um 14:39 schrieb Sergii Stoian : >> On Sun, Nov 24, 2019 at 11:34 AM Fred Kiefer wrote: >>> Am 23.11.2019 um 23:33 schrieb Sergii Stoian : >>> I havent tried in the last weeks/months, but the last release worked. Of course, it has all specific "issues" of art which where never solved. But it is faster for certain operations and curves and anti-aliasing are exquisite. Using Graphos on art is a delight. >>> What do you mean by “worked”? I observed incomplete words in menus and >>> popup buttons. Incorrect alignment of items in popup buttons - I suppose >>> it’s due to incorrect lengthOfString results. Also I suppose I’ve found >>> cause of a problem - NSStringDrawing caching methods rewrite by Fred. But I >>> can’t understand what changes must be applied to ART backend to adopt new >>> caching algorithm. >> >> I am willing to help here if you could pinpoint the issue a bit down. Which >> commit are you talking about and in which situations does it show? The last >> time I used the art backend I did not see any issues. But I must confess I >> only checked with Ink. >> >> I've made some screenshots with 0.27 version of GUI and Back (please see >> attachments) to illustrate some inconsistencies. >> FontPreferencesPopUp and LocalizationPreferences-* illustrate NSPopUpButton >> text drawing. >> WorkspaceMenu+HelpPanel illustrates - i guess - related problem: "Workspace" >> menu lacks border at the right side. >> The other problem is with my custom HelpPanel that contains NSMatrix with >> index list (note selection offset). >> Plus (it's hard to make screenshot of insertion point) in NXTHelpPanel's >> NSTextField insertion point drawn shifted at 20-30 pixels to the right until >> there's no entered text. >> >> Now I'm using 0.25 version of GUI and Back - all works correcly. >> Somewhere between 0.25 and 0.25.1 of GUI NSStringDrawing was massively >> changed by you. Do you know what is the cause of these inconsistencies? > > With the recent mail flood on the GNUstep mailing lists I require some more > background to be sure we talk about the same thing here. > > The screenshots you made were for the art backend? Exactly. > 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. > 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. > 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. > If you want to debug the popup button issue you should start off with the > NSMenuItemCell drawing methods, here drawTitleXXX is the most likely starting > point. I’ve done it once I found inconsistency. NSMenu* code simply makes call to string drawing methods. > > Cheers, > Fred Sergii
Re: Art backend Was: Package building
HI Sergii, > Am 03.12.2019 um 14:39 schrieb Sergii Stoian : > On Sun, Nov 24, 2019 at 11:34 AM Fred Kiefer wrote: > > Am 23.11.2019 um 23:33 schrieb Sergii Stoian : > > > >> I havent tried in the last weeks/months, but the last release worked. Of > >> course, it has all specific "issues" of art which where never solved. But > >> it is faster for certain operations and curves and anti-aliasing are > >> exquisite. Using Graphos on art is a delight. > >> > > What do you mean by “worked”? I observed incomplete words in menus and > > popup buttons. Incorrect alignment of items in popup buttons - I suppose > > it’s due to incorrect lengthOfString results. Also I suppose I’ve found > > cause of a problem - NSStringDrawing caching methods rewrite by Fred. But I > > can’t understand what changes must be applied to ART backend to adopt new > > caching algorithm. > > I am willing to help here if you could pinpoint the issue a bit down. Which > commit are you talking about and in which situations does it show? The last > time I used the art backend I did not see any issues. But I must confess I > only checked with Ink. > > I've made some screenshots with 0.27 version of GUI and Back (please see > attachments) to illustrate some inconsistencies. > FontPreferencesPopUp and LocalizationPreferences-* illustrate NSPopUpButton > text drawing. > WorkspaceMenu+HelpPanel illustrates - i guess - related problem: "Workspace" > menu lacks border at the right side. > The other problem is with my custom HelpPanel that contains NSMatrix with > index list (note selection offset). > Plus (it's hard to make screenshot of insertion point) in NXTHelpPanel's > NSTextField insertion point drawn shifted at 20-30 pixels to the right until > there's no entered text. > > Now I'm using 0.25 version of GUI and Back - all works correcly. > Somewhere between 0.25 and 0.25.1 of GUI NSStringDrawing was massively > changed by you. Do you know what is the cause of these inconsistencies? With the recent mail flood on the GNUstep mailing lists I require some more background to be sure we talk about the same thing here. The screenshots you made were for the art backend? 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? 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? 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. If you want to debug the popup button issue you should start off with the NSMenuItemCell drawing methods, here drawTitleXXX is the most likely starting point. Cheers, Fred
Re: Art backend Was: Package building
Hi Fred, On Sun, Nov 24, 2019 at 11:34 AM Fred Kiefer wrote: > > > > Am 23.11.2019 um 23:33 schrieb Sergii Stoian : > > > >> I havent tried in the last weeks/months, but the last release worked. > Of course, it has all specific "issues" of art which where never solved. > But it is faster for certain operations and curves and anti-aliasing are > exquisite. Using Graphos on art is a delight. > >> > > What do you mean by “worked”? I observed incomplete words in menus and > popup buttons. Incorrect alignment of items in popup buttons - I suppose > it’s due to incorrect lengthOfString results. Also I suppose I’ve found > cause of a problem - NSStringDrawing caching methods rewrite by Fred. But I > can’t understand what changes must be applied to ART backend to adopt new > caching algorithm. > > I am willing to help here if you could pinpoint the issue a bit down. > Which commit are you talking about and in which situations does it show? > The last time I used the art backend I did not see any issues. But I must > confess I only checked with Ink. > > I've made some screenshots with 0.27 version of GUI and Back (please see attachments) to illustrate some inconsistencies. FontPreferencesPopUp and LocalizationPreferences-* illustrate NSPopUpButton text drawing. WorkspaceMenu+HelpPanel illustrates - i guess - related problem: "Workspace" menu lacks border at the right side. The other problem is with my custom HelpPanel that contains NSMatrix with index list (note selection offset). Plus (it's hard to make screenshot of insertion point) in NXTHelpPanel's NSTextField insertion point drawn shifted at 20-30 pixels to the right until there's no entered text. Now I'm using 0.25 version of GUI and Back - all works correcly. Somewhere between 0.25 and 0.25.1 of GUI NSStringDrawing was massively changed by you. Do you know what is the cause of these inconsistencies? -- Sergii Stoian, ProjectCenter lead developer NEXTSPACE owner, lead developer
Re: Art backend Was: Package building
On 24 Nov 2019, at 11:32, Fred Kiefer wrote: > >> Am 23.11.2019 um 23:33 schrieb Sergii Stoian : >> >>> I havent tried in the last weeks/months, but the last release worked. Of >>> course, it has all specific "issues" of art which where never solved. But >>> it is faster for certain operations and curves and anti-aliasing are >>> exquisite. Using Graphos on art is a delight. >>> >> What do you mean by “worked”? I observed incomplete words in menus and popup >> buttons. Incorrect alignment of items in popup buttons - I suppose it’s due >> to incorrect lengthOfString results. Also I suppose I’ve found cause of a >> problem - NSStringDrawing caching methods rewrite by Fred. But I can’t >> understand what changes must be applied to ART backend to adopt new caching >> algorithm. > > I am willing to help here if you could pinpoint the issue a bit down. Which > commit are you talking about and in which situations does it show? > The last time I used the art backend I did not see any issues. But I must > confess I only checked with Ink. > Sure. I need some time to recover my previous attempt. I’ll keep you informed.
