#143 Bug when useing plplot in GTK3

None
closed-fixed
nobody
None
5
2014-03-06
2014-01-20
Jens
No

Hallo Plplot developpers,

I have a small application using plplot inside a GTK3 window. This
uses the xcairo driver. I followed the example
extXdrawable_demo.c which I ported to GTK3, see attachment.

1 Attachments

Discussion

  • Jens

    Jens - 2014-01-20

    ... (contiuned).

    When I enlarge the window in horizontal direction some lines a plotted towards the negative direction.

    I could trace the problem in the code to a variable of type "short"
    that overflows and, hence, has negative values (in file plline.c function plP_pllclp). I think Arjen is aware of that problem, he left a comment.

    I solved my problem by changing the "downscale" variable in the cairo driver.

    file cairo.c lines 1324
    function stream_and_font_setup

    ...
    if ( pls->xlength > pls->ylength )
    downscale = (double) 2.0pls->xlength / (double) ( PIXELS_X - 1 );
    else
    downscale = (double) 2.0
    pls->ylength / (double) PIXELS_Y;
    ...

    In words: I doubled the value of downscale and probably did not solve the proble but moved it to larger windows.

    What do you think?
    I that a change that you are willing to add to the source?

    Best regards

    Jens

     
  • Alan W. Irwin

    Alan W. Irwin - 2014-01-20

    Aside.... You forgot necessary multiplication symbols "*" in your code above, but I understand what you are driving at.

    Here is some background on the scaling that goes on for most device drivers. Currently, one of the limitations of the PLplot library is that it stores positions as short integers. (We have discussed moving to 64-bit floating precision in the past for these internal coordinates, but have not done that yet.) So to get maximum resolution, we map coordinates for each device into these internal short coordinates and vice versa using "downscale" or "scale" commands like above (without the 2.0). So if you multiply that scaling factor by 2 you either overflow the short (which did not happen in your case) or compromise the resolution. (Try multiplying by a larger factor like 200, and I suspect you will notice a severe degradation in resolution.)

    Obviously every resize operation should update pls->xlength, pls->ylength, and the downscale factor appropriately. From what you report, my guess is the logic for those necessary updates on resizing is not working correctly for the cairo device driver, and if you find that is the case, I would be happy to accept your patch to fix the issue.

     
  • Jens

    Jens - 2014-01-24

    Hi Alan,

    thanks for the explanation.
    If I understand you correctly it might as well be that the values pls->xlength and pls->ylength are not correctly updated when the window is resized. What I see is that pls->xlength and pls->ylength are updated after downscale is computed.
    So I come up with a new suggestion, to recompute downscale after the call to
    XGetGeometry which retrieved the size.

    My test implementation of that idea is around line 2185:

    /* ... */
     XGetGeometry( aStream->XDisplay, aStream->XWindow, &rootwin,
            &x, &y, &w, &h, &b, &d );
    printf("XGetGeometry %i %i\n",w,h);
        pls->xlength = (PLINT) w;
        pls->ylength = (PLINT) h;
    
    /*reset donwscale -- Jens*/
    if ( pls->xlength > pls->ylength )
      aStream->downscale = (double) pls->xlength / (double) ( PIXELS_X - 1 );
    else
      aStream->downscale = (double) pls->ylength / (double) PIXELS_Y;
    
    /* ... */
    

    That code avoids the issues you mentioned with the resolution and fix my problem.

    Do you see any counter indications to this?

     
  • Alan W. Irwin

    Alan W. Irwin - 2014-03-06
    • status: open --> closed-fixed
    • Group: -->
     
  • Alan W. Irwin

    Alan W. Irwin - 2014-03-06

    Hi Jens:

    Sorry I took so long to respond, but I am still getting used to this allura form of bug tracker which by default did not inform me of your additional post which I found just now almost by accident.

    Your solution is exactly right, and I have tested and applied it to the svn trunk version of PLplot which will form the basis of our next release.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks