bugGNU Octave - Bugs: bug #33118, FLTK and Qt: text rotation fails...

 
 

bug #33118: FLTK and Qt: text rotation fails for angles other than 90 degrees

Submitter:  None
Submitted:  Tue 19 Apr 2011 05:27:18 AM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Dan Newman Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * dev
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 15 Mar 2021 10:59:06 AM UTC, comment #27: 

I opened bug #60236 for the issue noticed in comment #19.

Markus Mützel <mmuetzel>
Group administrator
Mon 15 Mar 2021 02:24:15 AM UTC, comment #26: 

can run a quick matlab test if someone has a succinct test script.

Nicholas Jankowski <nrjank>
Group Member
Sun 14 Mar 2021 04:02:26 PM UTC, comment #25: 

@Rik: The issue you noticed only happens with -dpdf (and -dps) paged devices: the problem is that the page is too small for the figure to fit in. In Octave 6, we switched to having the "paperpositionmode" property "auto" by default hence the difference with Octave 5.2: if the onscreen figure is larger than the "papersize", part of the figure are drawn outside the page. What does matlab do in this case? At least a warning would not hurt.

Pantxo Diribarne <pantxo>
Group Member
Sun 14 Mar 2021 08:45:44 AM UTC, comment #24: 

Octave is working as expected with a clean build.
So what I saw was most likely some local change that caused the issue for me.
Sorry for the noise.

IIUC, the on-screen results don't take advantage of FreeType's anti-aliasing capabilities. But `print` results are (and have been) of high quality. So there might still be room to improve the on-screen results.
Pantxo's change fixes the immediate issue of rotated text disappearing on-screen. That is a huge improvement. From my point of view, that means that this report can be considered as fixed.

If someone would like to improve the on-screen results, we could track that in a new report (or re-open this one).

Markus Mützel <mmuetzel>
Group administrator
Sat 13 Mar 2021 03:12:36 PM UTC, comment #23: 

Running `test getframe` causes Octave to close unexpectedly on Windows. Attaching gdb to the Octave process before that command yields the following:

(gdb) c
Continuing.
[Thread 13556.0x3060 exited with code 0]
[New Thread 13556.0x36a0]
[Thread 13556.0x36a0 exited with code 0]
[New Thread 13556.0x41b8]
[New Thread 13556.0x3d18]
[New Thread 13556.0x3c18]
[New Thread 13556.0x2e8]
[New Thread 13556.0x4790]
[New Thread 13556.0x2244]
[New Thread 13556.0xd58]
[New Thread 13556.0x1f78]
warning: ../src/gallium/auxiliary/util/u_simple_shaders.c:680:util_make_fs_blit_msaa_depthstencil: Assertion `0' failed.
[Thread 13556.0x1fe0 exited with code 3]
[Thread 13556.0x2e8 exited with code 3]
[Thread 13556.0x3d18 exited with code 3]
[Thread 13556.0x4790 exited with code 3]
[Thread 13556.0xd58 exited with code 3]
[Thread 13556.0x1f78 exited with code 3]
[Thread 13556.0x4780 exited with code 3]
[Thread 13556.0x2244 exited with code 3]
[Thread 13556.0x3c18 exited with code 3]
[Thread 13556.0x41b8 exited with code 3]
[Thread 13556.0x3518 exited with code 3]
[Thread 13556.0x198c exited with code 3]
[Thread 13556.0x2540 exited with code 3]
[Thread 13556.0x21f4 exited with code 3]
[Thread 13556.0x6b8 exited with code 3]
[Thread 13556.0x468c exited with code 3]
[Thread 13556.0x2a74 exited with code 3]
[Thread 13556.0x113c exited with code 3]
[Thread 13556.0x46bc exited with code 3]
[Thread 13556.0x47b0 exited with code 3]
[Thread 13556.0x3080 exited with code 3]
[Thread 13556.0x39c8 exited with code 3]
[Thread 13556.0x580 exited with code 3]
[Thread 13556.0x44dc exited with code 3]
[Thread 13556.0x2584 exited with code 3]
[Thread 13556.0x45c8 exited with code 3]
[Thread 13556.0x45ac exited with code 3]
[Thread 13556.0x262c exited with code 3]
--Type <RET> for more, q to quit, c to continue without paging--
[Inferior 1 (process 13556) exited with code 03]
(gdb)


I'm not sure if this is related to this change because I also built with some other local changes.

The function that throws the assertion failure seems to be the following one from mesa3d:
https://gitlab.freedesktop.org/mesa/mesa/-/blob/staging/20.2/src/gallium/auxiliary/util/u_simple_shaders.c#L652

/**
 * Make a fragment shader that sets the output depth and stencil to depth
 * and stencil values fetched from two multisample textures / samplers.
 * The sizes of both textures should match (it should be one depth-stencil
 * texture).
 * \param tex_target  one of PIPE_TEXTURE_x
 */
void *
util_make_fs_blit_msaa_depthstencil(struct pipe_context *pipe,
                                    enum tgsi_texture_type tgsi_tex)
{
   static const char shader_templ[] =
         "FRAG\n"
         "DCL IN[0], GENERIC[0], LINEAR\n"
         "DCL SAMP[0..1]\n"
         "DCL SVIEW[0..1], %s, FLOAT\n"
         "DCL OUT[0], POSITION\n"
         "DCL OUT[1], STENCIL\n"
         "DCL TEMP[0]\n"

         "F2U TEMP[0], IN[0]\n"
         "TXF OUT[0].z, TEMP[0], SAMP[0], %s\n"
         "TXF OUT[1].y, TEMP[0], SAMP[1], %s\n"
         "END\n";

   const char *type = tgsi_texture_names[tgsi_tex];
   char text[sizeof(shader_templ)+100];
   struct tgsi_token tokens[1000];
   struct pipe_shader_state state = {0};

   assert(tgsi_tex == TGSI_TEXTURE_2D_MSAA ||
          tgsi_tex == TGSI_TEXTURE_2D_ARRAY_MSAA);

   sprintf(text, shader_templ, type, type, type);

   if (!tgsi_text_translate(text, tokens, ARRAY_SIZE(tokens))) {
      assert(0);
      return NULL;
   }
   pipe_shader_state_from_tgsi(&state, tokens);
#if 0
   tgsi_dump(state.tokens, 0);
#endif

   return pipe->create_fs_state(pipe, &state);
}


I'll try if I can reproduce with a clean build.

Markus Mützel <mmuetzel>
Group administrator
Sat 13 Mar 2021 12:16:25 AM UTC, comment #22: 

@Pantxo: I also checked and in 6.2 there is also a problem when the onscreen figure is re-sized.  It works, however, in 5.2.  So the issue of a clipped axes does not seem related to this change and probably deserves it's own bug report.

Rik <rik5>
Group administrator
Fri 12 Mar 2021 11:05:12 PM UTC, comment #21: 

@Rik: Sorry, I just noticed that in your screenshots the figure didn't have the default size. If I enlarge the figure, the problem indeed occurs here as well. I'll look into this.

Pantxo Diribarne <pantxo>
Group Member
Fri 12 Mar 2021 11:01:01 PM UTC, comment #20: 

I cannot reproduce the regression with the PDF format: for me, whether using -svgconvert or not, the -dpdf and -dpdfcrop   outputs (attached) still look good:


demo text 1
print -dpdfcrop toto.pdf


(file #51054)

Pantxo Diribarne <pantxo>
Group Member
Fri 12 Mar 2021 10:36:49 PM UTC, comment #19: 

As expected with a large code change, there have been some unintended side effects.  I've also attached the files from printing the plot to PDF output.  In Octave version 6.2 the plot is correctly sized and includes the axes and axes labels.  After this change, the development version of Octave no longer includes the y-axis and label in the output PDF.

Rik <rik5>
Group administrator
Fri 12 Mar 2021 10:33:22 PM UTC, comment #18: 

Even with sub-par rendering from textures, the result is a lot better and closer to WYSIWYG (What You See Is What You Get) when printing.

demo #1 from text.m is a good test case for this.  Here is the output in version 6.2 which only supports rotation in increments of 90 degrees.



And here is the result on the development branch that includes the new code


Rik <rik5>
Group administrator
Fri 12 Mar 2021 08:56:23 PM UTC, comment #17: 

Thanks Markus for the feedback. I pushed the patch, polished after your suggestions:

http://hg.savannah.gnu.org/hgweb/octave/rev/8811d8274118

Marking ready for test.

Pantxo Diribarne <pantxo>
Group Member
Fri 12 Mar 2021 04:59:31 PM UTC, comment #16: 

The results with that patch are definitely better than what we have at the moment imho.

Just some minor nitpicking: There are a couple of places where there are multiple line breaks or trailing white spaces in the modified lines.
Also one line break in the commit message seems to be off.
After changing those, I'd say: go ahead and push to default.

Markus Mützel <mmuetzel>
Group administrator
Thu 11 Mar 2021 07:33:14 PM UTC, comment #15: 

In the attached patch, I went the lazy route of rotating a texture. As I had expected the quality is not great but I think it is an improvement over the current situation. What do you think?

(file #51046)

Pantxo Diribarne <pantxo>
Group Member
Sun 03 Mar 2019 07:36:38 PM UTC, comment #14: 

I think resolving this bug should be something to strive for in the next major release of Octave (6.0.0).  This is one of the last areas in plotting where the screen display does not match the printed output.

Following Pantxo's suggestion, I did a quick google search of "rotate text freetype" and there are many hits, including for our specific case of using FreeType and OpenGL together.

Rik <rik5>
Group administrator
Thu 22 Dec 2016 04:54:44 PM UTC, comment #13: 

Understood.  So this is really a much bigger project than just a rotation matrix.  I suppose it might be possible to start with the ugly solution, just to get something working onscreen, and then figure out the correct solution with Freetype later.

Rik <rik5>
Group administrator
Thu 22 Dec 2016 11:57:39 AM UTC, comment #12: 

Just a note:
Almost 2 years ago I started a repo on github https://github.com/Andy1978/octave-debug-text-renderer for this issue. Perhaps it's worth a look...

Andreas Weber <andy1978>
Group Member
Thu 22 Dec 2016 09:53:30 AM UTC, comment #11: 

@Rik:

>> It seems that as a first take, we could just calculate a rotation matrix (R) and then use ...


Yes, one could try this approach but I fear that the result would be of poor quality. Freetype initially applies antialiasing on glyphs so that they are rasterized smoothly on the original grid. After rotation one would have to interpolate pixels colors to make them fit into the output pixmap (see "imtransform" in the image package) and antialiasing would then be lost.

Freetype has tools to rotate/transform glyphs before rasterization but it would be a deeper change into txt-renderer.cc

Pantxo Diribarne <pantxo>
Group Member
Tue 20 Dec 2016 09:46:46 PM UTC, comment #10: 

I'm adding Pantxo to the CC list for this 5-year old bug because he often has a good understanding of OpenGL.  In this case, the issue seems to have been traced back to the function


  ft_text_renderer::render (text_element *elt, Matrix& box, int rotation)


which is in libinter/corefcn/ft-text-renderer.cc:1113.

It seems that as a first take, we could just calculate a rotation matrix (R) and then use


pixels = R * pixels;


since the multiplication operator should be defined for uint8NDArray types.


Rik <rik5>
Group administrator
Thu 08 Dec 2016 03:56:03 AM UTC, comment #9: 

issue still exists in Octave 4.2.0 using comment #5 example in the qt and fltk toolkits, but not gnuplot (text is rotated in gnuplot). saved pdfs still have correct rotated text.

Nicholas Jankowski <nrjank>
Group Member
Mon 13 Jun 2016 09:54:47 AM UTC, comment #8: 
Tatsuro MATSUOKA <tmacchant>
Thu 05 Feb 2015 06:18:54 AM UTC, comment #7: 

This is still present on the current development version, and affects both the FLTK and Qt toolkits. Updating version and summary.

Mike Miller <mtmiller>
Group Member
Sun 18 Sep 2011 03:26:21 PM UTC, comment #6: 

I've changed the summary

Ben Abbott <bpabbott>
Group Member
Wed 20 Apr 2011 03:57:15 PM UTC, comment #5: 

Confirmed that this is a rendering issue as printing works correctly.


plot (1:10);
text (2, 6, "Hello World", "Rotation", 45);
print -dpdf rot_test.pdf


Good work by Andreas in identifying the problem file and area.  It looks to me like we are maintaining the pixels in an Octave uint8NDarray already.  This means we could probably just use a rotation matrix in Octave rather than calling out to FreeType.  I don't mess with the graphics area much, however, so someone else will have to do any coding in this area.

Rik <rik5>
Group administrator
Wed 20 Apr 2011 12:18:47 PM UTC, comment #4: 

I had now a deeper look on this. Please keep in mind that I am a beginner with the octave source code and some asumptions might be false.

hg id = f212ff846296

Since the text is rendered into a bitmap with freetype, fltk does not rotate the text. Rather in
  opengl_renderer::text_to_pixels
which calls
  text_renderer.text_to_pixels

int ft_render::rotation_to_mode (double rotation) const;
does only accept 0,90,180,270 deg, all values which does not mache are set to 0

The "rotation" is done in txt-eng-ft.cc, ft_render::render
with "pixels = pixels.permute (perm);"

I guess if instead the FreeType function FT_Set_Transform
is used, we can display arbitrary rotated text and can get rid of the "permute". (see http://www.freetype.org/freetype2/docs/tutorial/step1.html)

Andy


Andreas Weber <andy1978>
Group Member
Wed 20 Apr 2011 07:34:51 AM UTC, comment #3: 

I think FLTK can draw rotated text with fl_rotate and fl_draw.

I stepped through the code and found in
txt-eng-ft.cc:394:ft_render::render (text_element* elt, Matrix& box, int rotation) a switch for ROTATION_0, ROTATION_90, ROTATION_180 and ROTATION_270

All values outside x*90 are mapped to ROTATION_0 in ft_render::rotation_to_mode (double rotation) const.

I'm really not familiar with the octave internals but it seems to me like the text gets rendered with freetype and the fltk functions only draw the resulting bitmap in
opengl_renderer::render_text
gl-render.cc:2992: glDrawPixels (bbox(2), bbox(3),           GL_RGBA, GL_UNSIGNED_BYTE, pixels.data ());

btw: If I want to compile octave-dev with debugging symbols, what is the prefered way? Now I made a
../octave/configure --enable-shared --disable-static
make CFLAGS="-O0 -ggdb" CXXFLAGS="-O0 -ggdb"

is this sufficient?
Andy

Andreas Weber <andy1978>
Group Member
Wed 20 Apr 2011 02:27:03 AM UTC, comment #2: 

I think this is a limitation of FLTK.

http://www.fltk.org/wiki.php?V366+TC+Q

However, GL2PS does not have this limitation. Thus, output obtained using the print() function should be correct.

Ben Abbott <bpabbott>
Group Member
Tue 19 Apr 2011 06:35:25 PM UTC, comment #1: 

Confirmed on a recent development tip (4/19/2011).

Rik <rik5>
Group administrator
Tue 19 Apr 2011 05:27:18 AM UTC, original submission:  

The "Rotation" property is not handled correctly by the text() function.  For angles which are positive multiples of 90, the plotted result is correct.  For other angles, the text is plotted at a rotation angle of 0.

This failure only occurs onder fltk.  Gnuplot produces the correct result.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #51054:  toto.pdf added by pantxo (12KiB - application/pdf)
file #51050:  text_demo1.v6.2.png added by rik5 (56KiB - image/png)
file #51051:  text_demo1.vdev.png added by rik5 (109KiB - image/png)
file #51052:  text_demo1.v6.2.pdf added by rik5 (4KiB - application/pdf)
file #51053:  text_demo1.vdev.pdf added by rik5 (4KiB - application/pdf)
file #51046:  bug33118.patch added by pantxo (18KiB - text/x-patch)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by gyom
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by tmacchant (Posted a comment)
  • -email is unavailable- added by andy1978 (Posted a comment)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 19 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-03-14 mmuetzel StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2021-03-12 pantxo Attached File- Added toto.pdf, #51054
    2021-03-12 rik5 Attached File- Added text_demo1.v6.2.png, #51050
        Attached File- Added text_demo1.vdev.png, #51051
        Attached File- Added text_demo1.v6.2.pdf, #51052
        Attached File- Added text_demo1.vdev.pdf, #51053
    2021-03-12 pantxo StatusPatch Submitted Ready For Test
    2021-03-11 pantxo Attached File- Added bug33118.patch, #51046
        StatusConfirmed Patch Submitted
    2019-03-03 mtmiller Carbon-CopyRemoved 80942 -
    2018-11-06 gyom Carbon-Copy- Added gyom
    2016-12-20 rik5 Carbon-Copy- Added pantxo
    2015-02-05 mtmiller Release3.4.0 dev
        Operating SystemGNU/Linux Any
        SummaryFLTK text rotation fails for angles other than 90 deg FLTK and Qt: text rotation fails for angles other than 90 degrees
    2014-12-26 rik5 Dependencies- bugs #32332 is dependent
    2011-09-18 bpabbott Summarytext rotation fails for angles other than 90 deg FLTK text rotation fails for angles other than 90 deg
    2011-04-19 rik5 StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code