octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #52940] Regression with "PaperPosition" and pr


From: Pantxo Diribarne
Subject: [Octave-bug-tracker] [bug #52940] Regression with "PaperPosition" and printing
Date: Sun, 28 Jan 2018 17:00:53 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0

Follow-up Comment #36, bug #52940 (project octave):

@Rik, @Dan: 
>> A useful reason to pursue Dan's strategy would be the printing of legend
objects ...

Rescaling figures at print time will always have to happen unless the aspect
ratio of "paperposition" and "position" figure properties match (at the very
least). For this reason "position" *needs to be correct* so the listeners that
rely on it (in user code or internal code) can do their job. 
"legend" and "colorbar" have to be fixed, at least for on-screen experience
(look how ridiculous legends become when you rescale a figure by hand) and no
print-time trick will workaround this.


>> I agree with your comment #32 that the best course is probably " Move the
update_aspectratios(), update_camera() and update_axes_layout() code from
axes::properties to the opengl_renderer object" 

At first glance, I am not fond of the idea of moving the routines that compute
opengl matrices from axes objects, where they are executed only when some
property change justifies it, to opengl_renderer, where those routines will be
executed each and every time the graphics toolkit calls
opengl_renderer::draw.

Is this all just about avoiding the figure window being rescaled?
Why not simply implement something like graphics_tookit::block_size_updates ()
so that we have the graphics objects right and the figure window size is not
updated ?

I didn't take the time to read all the posts but my first impression is that
if a big change has to happen then we should also try looking at what exists
in the modern opengl API. There are now objects (framebuffer objects and
associated renderbuffer objects) that allow rendering offscreen and without
bothering about the size of the windowing system provided framebuffer (the
default framebuffer object). I don't really know how big of a change this is,
but it is definitely a route we should investigate.



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52940>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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