[ft-devel] GSoC: OT-SVG update and a performance issue

[Moazin Khatri]

Hi,

I have changed the code to get the bounding box by using a
`cairo_recording_surface' instead of relying on CFF/TFF outline bounding
boxes. The code works great and Bixa Color is being rendered properly too.
I have also changed `ft_glyphslot_preset_bitmap' to work with OT-SVG
glyphs, so now, the slot will be preset at the loading stage.

However, there is one performance concern I have:

Since the bitmap presetting of an OT-SVG glyph can only be done by the
"rendering port", I had to create a hook function called `preset_slot'.
Then I create a wrapper function around it in my `ot-svg' module and this
wrapper function gets exposed via the interface of the `ot-svg' module.
Ultimately, this function gets used in `ft_glyphslot_preset_bitmap' for
presetting an OT-SVG glyph.

This hook function (for librsvg) would work in the following manner:
* create a cairo recording surface
* render the glyph on that surface (you'll have to check whether to render
the whole document or a particular element)
* get the bounds
* perform any transformations on the bounds if necessary and then preset
the slot

At the end of `FT_Load_Glyph' you'll see that it calls
`ft_glyphslot_preset_bitmap' only if `FT_LOAD_RENDER' has not been passed.
Which indicates that `FT_Render_Glyph' shouldn't really care whether
presetting was done or not. In fact, in `ft_smooth_render_generic',
`ft_glyphslot_preset_bitmap' is called again. I have to replicate the same
behavior with OT-SVG. Thus, in `ft_svg_render', I call the preset hook
again to be sure that presetting is done, this is so that I can use the
width/height to allocate memory before calling the render hook. Then in
render hook, once again the same recording surface calculations will need
to be done to get the bounding box (which is necessary for rendering).

So you see, the same thing is being done 3 times. I just need this
information to persist in an accurate manner so I can reuse it instead of
calculating it again and again. I have managed to reduce this to 2 by doing
this:

The preset hook function takes an argument called `cache' (just a name, can
change), if this is set to TRUE, it'll store all of its calculations inside
the state of the rendering port. When `ft_svg_render' calls the preset hook
it'll set `cache' to TRUE, thus all calculations will be stored in the
rendering port's state and then the render hook can just use those. When
`FT_Load_Glyph' calls `ft_glyphslot_preset_bitmap', it'll call the wrapper
function with `cache' set to FALSE, thus, no state gets stored then.

Thus there is a possible repetition here (which is also present in the case
of traditional glyphs). if there's a better way to do this, let me know.
Should we worry about this performance concern?

Moazin
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC'19] ftinspect update

[Triplex]

Hi Werner,

Thanks for the descriptive feedback and I'll make sure to
fix the issues ASAP.


> * The biggest problem is that glyphs in the `ftview' mode aren't
>   displayed with correct vertical positions.  This is serious bug and
>   must be fixed ASAP – I think I reported this already six weeks
>   ago...
>

This actually is a problem. I tried some ways to fix the same. I'll
try fixing the same ASAP.

* I don't like that there are tabs called `Ftview' or `Ftdiff'; a new
>   user has no idea what this is for.  Instead, if you select one of
>   the `modes' with the radio buttons, the tabs on the left side should
>   change according to the mode (having functional names that helps the
>   user in navigation), and/or features that don't fit should be greyed
>   out.
>

I think you must have compiled the program from 'gsoc-2019-experimental'
branch. It's not completely updated. For the same reason I attached a small
introduction video.
So, options have been properly grayed out and tabs also have functional
names now.

Another issue is that selecting stuff from the tab suddenly changes
>   the mode; for example, if I select `Grid View', then `Ftview->Render
>   Mode->Stroked', the display no longer is in grid mode (but the radio
>   button still shows it).  This must not happen.  As mentioned above,
>   options that do not fit a mode must be disabled (or not displayed).
>

This also have been done.

* If a dark desktop theme gets used, the background of the main window
>   becomes dark, too.  This is quite bad, since the various gray shades
>   are no longer displayed correctly.  Please ensure that always a
>   white background gets used.
>

This part I haven't had a look at. I'll make sure to fix it.

* `Segment Drawing' doesn't work correctly.  Segment lines appear for
>   half a second, then they disappear again.  Additionally, it seems
>   that if both horizontal and vertical auto-hinting is selected, even
>   the short appearance can't be triggered.
>

This is not the case now. It works as it is expected to work.

  By the way, the segment lines are too thick now.  If the grid line
>   has a thickness of 1px, I suggest that segment lines are 2px thick
>   (i.e., ½px + 1px + ½px).
>

Sure! I'll make it a quick fix.

>
> * The `All Glyphs' mode is mostly dysfunctional.  For example, the
>   display doesn't get updated if I select auto-hinting.


Thanks for pointing out. I just noticed it. It was because of wrong
functional
call.

Similarly,
>   pressing the `+10' button (and friends) only adjusts a single, red
>   outlined glyph that is always positioned in the center – what is
>   this good for?


That was supposed to be disabled while changing to 'All Glyphs' and
now it is disable as soon as we change to other modes. Same goes for
'+10' button (and friends).

* Another issue with the `All Glyphs' mode: If I select a large size
>   (say, 100px), I can't move the image around with my mouse.  Ditto
>   for `Comparator' mode.
>

I disabled the drag mode in those modes. Since, everything
that was supposed to be viewed was displayed within the given
area. I didn't go through the possibility of changing pixel sizes in
these modes. Should I enable it back? And handle larger size in those
modes too?

* If I select a large size in `All Glyphs' mode, then select `Grid
>   View' the size gets respected.  However, selecting `All Glyphs' mode
>   again, the size jumps back to a default size of 20px.
>

This is also on purpose. Because otherwise user had to scroll over the
canvas to search for the results if the size is too large. Thus changing the
size makes it easy to notice the mode change.

* All modes except `Grid View' mode lag a lot if I change parameters,
>   or if I move the panel with the mouse – this indicates a problem
>   with the implementation.  Please fix that.  It must work as swift as
>   the `Grid View' mode.
>

I'll see to that. Thanks for pointing it out.

* Please display number values on the Gamma scale (i.e., using a
>   different widget for the scale).
>

Noted.

* The Gamma scale behaves strangely: selecting values at the very
>   left, the image be brighter again!  This can't be correct.
>

Yeah, I guess. Although I followed the below solution to achieve the current
implementation
.


> * Gamma values should work in all modes, not only `Grid View'.
>

That is also completed.

Thank you for pointing out all the issues with details. I'll make sure
to resolve all ASAP.

-- 
Veeki
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] GSoC: OT-SVG update and a performance issue

[Alexei Podtelezhnikov]

> This hook function (for librsvg) would work in the following manner:
> * create a cairo recording surface
> * render the glyph on that surface (you'll have to check whether to render 
> the whole document or a particular element)

This is unacceptable because it defeats the purpose. If the library
cannot return the bounding box without rendering, just forget it and
bail from ft_glyphslot_preset_bitmap. You and Behdad did however say
that say that it is available in some libraries.
https://lists.nongnu.org/archive/html/freetype-devel/2019-07/msg00128.html

> * get the bounds
> * perform any transformations on the bounds if necessary and then preset the 
> slot

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] GSoC: OT-SVG update and a performance issue

[Moazin Khatri]

Technically it isn't rendering it to pixel data. A Cairo recording surface
just records the drawing operations without rendering it to pixels (AFAIK).
Then it uses those recorded operations to find bounds.

On Thu, Aug 8, 2019, 9:54 PM Alexei Podtelezhnikov 
wrote:

> > This hook function (for librsvg) would work in the following manner:
> > * create a cairo recording surface
> > * render the glyph on that surface (you'll have to check whether to
> render the whole document or a particular element)
>
> This is unacceptable because it defeats the purpose. If the library
> cannot return the bounding box without rendering, just forget it and
> bail from ft_glyphslot_preset_bitmap. You and Behdad did however say
> that say that it is available in some libraries.
> https://lists.nongnu.org/archive/html/freetype-devel/2019-07/msg00128.html
>
> > * get the bounds
> > * perform any transformations on the bounds if necessary and then preset
> the slot
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] GSoC: OT-SVG update and a performance issue

[Alexei Podtelezhnikov]

> Technically it isn't rendering it to pixel data. A Cairo recording surface 
> just records the drawing operations without rendering it to pixels (AFAIK). 
> Then it uses those recorded operations to find bounds.

Why is it an issue even with clipping? The clipped bounding box can be
very well estimated as an overlap of (1) clipping path bbox and (2)
drawing path bbox. This should be good enough.

>> > This hook function (for librsvg) would work in the following manner:
>> > * create a cairo recording surface
>> > * render the glyph on that surface (you'll have to check whether to render 
>> > the whole document or a particular element)
>>
>> This is unacceptable because it defeats the purpose. If the library
>> cannot return the bounding box without rendering, just forget it and
>> bail from ft_glyphslot_preset_bitmap. You and Behdad did however say
>> that say that it is available in some libraries.
>> https://lists.nongnu.org/archive/html/freetype-devel/2019-07/msg00128.html
>>
>> > * get the bounds
>> > * perform any transformations on the bounds if necessary and then preset 
>> > the slot



-- 
Alexei A. Podtelezhnikov, PhD

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] GSoC: OT-SVG update and a performance issue

[Moazin Khatri]

>
> Why is it an issue even with clipping? [...]


Not a big issue. Such inaccuracies are rare, but when they do pop-up, the
inaccuracy isn't a problem. The same happens with Cbox calculation in
traditional glyphs and we are fine with it too. :) The glyph will still
land up at the right place.


> [...] The clipped bounding box can be
> very well estimated as an overlap of (1) clipping path bbox and (2)
> drawing path bbox. This should be good enough.
>

I guess that's an internal detail of bounding box calculation and we are
not dealing with that. The library authors or the authors of the graphic
backends should deal with this. We just use whatever they provide.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel