| NG: bring_to_front doesn't always work [message #89070] |
Tue, 22 July 2014 07:21  |
dg86
Messages: 118
Registered: September 2012
|
Senior Member |
|
|
Dear Folks,
In overlaying plots created with PLOT(), I've noticed that the ORDER
method sometimes doesn't work, or at least not completely. The plots in
question are reasonably complicated, and I haven't found a minimal
example. The idea is
p1 = PLOT(x1, y1)
p2 = PLOT(x2, y2, symbol='o', linestyle='',/sym_filled,sim_color='black',sim_fill_color='w hite',over=p1)
p3 = PLOT(x3, y3, over = p1)
p2.order, /bring_to_front
My goal is to have the filled circles from p2 appear over the curve from p3.
Instead, and only sometimes, the curve from p3 obscures some, but not all, of the
filled circles from p2.
This almost certainly is a bug. I'm running IDL 8.3 and have seen similar
behavior under linux and MacOS.
Changing the order of the PLOT commands would fix the problem,
but would make my plotting script less easy to read.
Is there an "in-place" workaround? Will this be fixed in 8.4?
Many thanks,
David
|
|
|
|
|
|
| Re: NG: bring_to_front doesn't always work [message #89210 is a reply to message #89208] |
Mon, 04 August 2014 18:35  |
dg86
Messages: 118
Registered: September 2012
|
Senior Member |
|
|
Dear Chris,
I believe I've narrowed it down. Error bars erroneously obscure some overlying plot
symbols provided that two conditions are met:
1. at least two data sets are plotted in the same plot using the OVER keyword and
2. the primary plot is resized using the POSITION keyword.
In this case, some of the plot symbols in the secondary plot will be obscured,
not the primary.
The following example is not exactly minimal, but reproducibly exercises the bug.
Set bug = 0 to turn the bug off.
Thanks for looking into this. TTFN,
David
===== cut here for example =====
bug = 1 ; buggy plot if true
colors = ['lavender', 'yellow']
symbols = ['s', 'o']
;;;;;
;
; The primary plot
;
; All is well unless this has its shape changed with the
; POSITION keyword
;
pos = [0.125, 0.11, 0.97, 0.97]
t = [15, 20, 25, 30, 40, 50, 60, 90, 120] ; sampling times [minutes]
ap = [0.422150, $
0.539150, $
0.646400, $
0.704250, $
0.730250, $
0.753000, $
0.754300, $
0.786150, $
0.781600] ; radius [micrometers]
dap = [[0.032500, 0.021450], $
[0.052650, 0.056550], $
[0.115050, 0.058500], $
[0.065000, 0.048750], $
[0.055250, 0.054600], $
[0.053300, 0.031850], $
[0.070850, 0.078000], $
[0.052650, 0.112450], $
[0.027300, 0.055250]] ; range of radii [micrometers]
pl = errorplot(t, ap, dap, linestyle = '', $
xrange = [0, 130], $
xtitle = 't [min]', ytitle = '$a_p(t)$ [$\mu$m]', $
errorbar_color = 'grey', $
font_size = 16)
ps = plot(t, ap, linestyle = '', sym_color = 'grey', sym_fill_color = colors[0],$
symbol = symbols[0], /sym_filled, sym_size = 1.2, $
sym_thick = 1.5, $
over = pl)
if bug then pl.position = pos
;;;;;
;
; The secondary plot
;
; Some, but not all plot symbols (circles) are obscured by vertical
; bar if the primary plot's shape was changed with the POSITION
; keyword
;
t = [15, 25, 35, 45, 60, 90]
ap = [0.502400, $
0.650400, $
0.835200, $
0.913600, $
0.976000, $
0.998400]
dap = [[0.036800, 0.035200], $
[0.032800, 0.040000], $
[0.054400, 0.044800], $
[0.060000, 0.049600], $
[0.057600, 0.049600], $
[0.047200, 0.042400]]
pl2 = errorplot(t, ap, dap, linestyle = '', over = pl)
ps2 = plot(t, ap, linestyle = '', sym_color = 'black', $
symbol = symbols[1], /sym_filled, sym_fill_color = colors[1], sym_size = 1.5, $
sym_thick = 2, $
over = pl)
;;;;;
;
; Even moving the symbols to the "front" doesn't fix the issue
;
ps2.order, /bring_to_front
;pl.save, 'minimal2.png', resolution = 150, border = 1
===== end of example =====
|
|
|
|
|
|
| Re: NG: bring_to_front doesn't always work [message #89224 is a reply to message #89223] |
Wed, 06 August 2014 12:50 |
dg86
Messages: 118
Registered: September 2012
|
Senior Member |
|
|
On Wednesday, August 6, 2014 1:05:34 PM UTC-4, Chris Torrence wrote:
> Hi David,
>
>
>
> I think this might be a bug in the Mesa OpenGL software-rendering library. Can you check your IDL preferences and see if you have "software" rendering enabled? If you do, can you switch it to "hardware" rendering and see if the problem goes away?
>
>
>
> -Chris
Dear Chris,
You may be right about the culprit being Mesa OpenGL.
I usually run IDL from emacs (or the command line) rather than from the Workbench, and so have
not fiddled with the settings for the graphics backend. I just fired up the IDL 8.3 Workbench and
tried to run my example script. It worked as usual with software rendering enabled, but not
at all with hardware rendering enabled, instead emitting error messages such as
% Graphics device not available: GL_COCOA.
% Attempt to destroy an object within its INIT method: <ObjHeapVar11153(GRAPHICSWIN)>.
% Execution halted at: $MAIN$
So, hardware rendering appears not to work at all(!).
I'm running IDL 8.3 under OS X 10.9.4 on a Macbook Pro.
All the best,
David
|
|
|
|
| Re: NG: bring_to_front doesn't always work [message #89225 is a reply to message #89224] |
Wed, 06 August 2014 12:58 |
chris_torrence@NOSPAM
Messages: 528
Registered: March 2007
|
Senior Member |
|
|
On Wednesday, August 6, 2014 1:50:06 PM UTC-6, David Grier wrote:
> On Wednesday, August 6, 2014 1:05:34 PM UTC-4, Chris Torrence wrote:
>
>> Hi David,
>
>>
>
>>
>
>>
>
>> I think this might be a bug in the Mesa OpenGL software-rendering library. Can you check your IDL preferences and see if you have "software" rendering enabled? If you do, can you switch it to "hardware" rendering and see if the problem goes away?
>
>>
>
>>
>
>>
>
>> -Chris
>
>
>
> Dear Chris,
>
>
>
> You may be right about the culprit being Mesa OpenGL.
>
> I usually run IDL from emacs (or the command line) rather than from the Workbench, and so have
>
> not fiddled with the settings for the graphics backend. I just fired up the IDL 8.3 Workbench and
>
> tried to run my example script. It worked as usual with software rendering enabled, but not
>
> at all with hardware rendering enabled, instead emitting error messages such as
>
>
>
> % Graphics device not available: GL_COCOA.
>
> % Attempt to destroy an object within its INIT method: <ObjHeapVar11153(GRAPHICSWIN)>.
>
> % Execution halted at: $MAIN$
>
>
>
> So, hardware rendering appears not to work at all(!).
>
>
>
> I'm running IDL 8.3 under OS X 10.9.4 on a Macbook Pro.
>
>
>
> All the best,
>
>
>
> David
Hmmm. Well, that's not good either. I've never seen that GL_COCOA error message. Unfortunately, I don't have any good answers for you.
This definitely won't get fixed in time for IDL 8.4, so I think your best bet is to avoid using the .Order method and just create the plots in the "correct" order.
Sorry about that.
-Chris
|
|
|
|
| Re: NG: bring_to_front doesn't always work [message #89226 is a reply to message #89225] |
Wed, 06 August 2014 14:12 |
dg86
Messages: 118
Registered: September 2012
|
Senior Member |
|
|
On Wednesday, August 6, 2014 3:58:25 PM UTC-4, Chris Torrence wrote:
> On Wednesday, August 6, 2014 1:50:06 PM UTC-6, David Grier wrote:
>
>> On Wednesday, August 6, 2014 1:05:34 PM UTC-4, Chris Torrence wrote:
>
>>
>
>>> Hi David,
>
>>
>
>>>
>
>>
>
>>>
>
>>
>
>>>
>
>>
>
>>> I think this might be a bug in the Mesa OpenGL software-rendering library. Can you check your IDL preferences and see if you have "software" rendering enabled? If you do, can you switch it to "hardware" rendering and see if the problem goes away?
>
>>
>
>>>
>
>>
>
>>>
>
>>
>
>>>
>
>>
>
>>> -Chris
>
>>
>
>>
>
>>
>
>> Dear Chris,
>
>>
>
>>
>
>>
>
>> You may be right about the culprit being Mesa OpenGL.
>
>>
>
>> I usually run IDL from emacs (or the command line) rather than from the Workbench, and so have
>
>>
>
>> not fiddled with the settings for the graphics backend. I just fired up the IDL 8.3 Workbench and
>
>>
>
>> tried to run my example script. It worked as usual with software rendering enabled, but not
>
>>
>
>> at all with hardware rendering enabled, instead emitting error messages such as
>
>>
>
>>
>
>>
>
>> % Graphics device not available: GL_COCOA.
>
>>
>
>> % Attempt to destroy an object within its INIT method: <ObjHeapVar11153(GRAPHICSWIN)>.
>
>>
>
>> % Execution halted at: $MAIN$
>
>>
>
>>
>
>>
>
>> So, hardware rendering appears not to work at all(!).
>
>>
>
>>
>
>>
>
>> I'm running IDL 8.3 under OS X 10.9.4 on a Macbook Pro.
>
>>
>
>>
>
>>
>
>> All the best,
>
>>
>
>>
>
>>
>
>> David
>
>
>
> Hmmm. Well, that's not good either. I've never seen that GL_COCOA error message. Unfortunately, I don't have any good answers for you.
>
>
>
> This definitely won't get fixed in time for IDL 8.4, so I think your best bet is to avoid using the .Order method and just create the plots in the "correct" order.
>
>
>
> Sorry about that.
>
>
>
> -Chris
Hi Again,
I can get around the ordering issue by resizing the plot window, rather than by using the position keyword. It's messy, but it works. It's funny that hardware rendering seems to be broken on this system. Could the problem be my version of XQuartz?
TTFN, and thanks again,
David
|
|
|
|
|
|
|
|
| Re: NG: bring_to_front doesn't always work [message #91806 is a reply to message #89224] |
Sun, 30 August 2015 10:38 |
wtcipher
Messages: 2
Registered: August 2015
|
Junior Member |
|
|
On Wednesday, August 6, 2014 at 12:50:06 PM UTC-7, David Grier wrote:
> On Wednesday, August 6, 2014 1:05:34 PM UTC-4, Chris Torrence wrote:
>> Hi David,
>>
>>
>>
>> I think this might be a bug in the Mesa OpenGL software-rendering library. Can you check your IDL preferences and see if you have "software" rendering enabled? If you do, can you switch it to "hardware" rendering and see if the problem goes away?
>>
>>
>>
>> -Chris
>
> Dear Chris,
>
> You may be right about the culprit being Mesa OpenGL.
> I usually run IDL from emacs (or the command line) rather than from the Workbench, and so have
> not fiddled with the settings for the graphics backend. I just fired up the IDL 8.3 Workbench and
> tried to run my example script. It worked as usual with software rendering enabled, but not
> at all with hardware rendering enabled, instead emitting error messages such as
>
> % Graphics device not available: GL_COCOA.
> % Attempt to destroy an object within its INIT method: <ObjHeapVar11153(GRAPHICSWIN)>.
> % Execution halted at: $MAIN$
>
> So, hardware rendering appears not to work at all(!).
>
> I'm running IDL 8.3 under OS X 10.9.4 on a Macbook Pro.
>
> All the best,
>
> David
Hey David,
I am currently having the same GL_COCOA problem while plotting. I realized that this only happen in workbench. If I run the routine in terminal, within IDL environment, there is no problem showing the figures. How about yours situation? Have you fixed it, yet?
This is my error message from workbench.
% Graphics device not available: GL_COCOA.
% Attempt to destroy an object within its INIT method: <ObjHeapVar52(GRAPHICSWIN)>.
% Execution halted at: $MAIN$
|
|
|
|
| Re: NG: bring_to_front doesn't always work [message #91807 is a reply to message #89224] |
Sun, 30 August 2015 10:43 |
wtcipher
Messages: 2
Registered: August 2015
|
Junior Member |
|
|
On Wednesday, August 6, 2014 at 12:50:06 PM UTC-7, David Grier wrote:
> On Wednesday, August 6, 2014 1:05:34 PM UTC-4, Chris Torrence wrote:
>> Hi David,
>>
>>
>>
>> I think this might be a bug in the Mesa OpenGL software-rendering library. Can you check your IDL preferences and see if you have "software" rendering enabled? If you do, can you switch it to "hardware" rendering and see if the problem goes away?
>>
>>
>>
>> -Chris
>
> Dear Chris,
>
> You may be right about the culprit being Mesa OpenGL.
> I usually run IDL from emacs (or the command line) rather than from the Workbench, and so have
> not fiddled with the settings for the graphics backend. I just fired up the IDL 8.3 Workbench and
> tried to run my example script. It worked as usual with software rendering enabled, but not
> at all with hardware rendering enabled, instead emitting error messages such as
>
> % Graphics device not available: GL_COCOA.
> % Attempt to destroy an object within its INIT method: <ObjHeapVar11153(GRAPHICSWIN)>.
> % Execution halted at: $MAIN$
>
> So, hardware rendering appears not to work at all(!).
>
> I'm running IDL 8.3 under OS X 10.9.4 on a Macbook Pro.
>
> All the best,
>
> David
Hello David,
I just fixed my problem right after posting here. I followed the instruction here
http://www.exelisvis.com/Support/HelpArticlesDetail/TabId/21 9/ArtMID/900/ArticleID/5294/5294.aspx
And follow this step
1.) Configure IDL to use Software Rendering.
a.) You can change your IDL preference to use Software rendering via the IDL Workbench Preferences dialog. From the "IDL" select "Preferences...". On the left pane of the Preferences dialog, expand IDL and select Graphics, and then on the right choose the "Default rendering method for object graphics" setting for Software (1)). Click Apply and then OK. (This approach can be used even if running IDL in unlicensed demonstration mode.)
Then the plotting issue within workbench is solved immediately.
Good luck! Hope that helps!
|
|
|
|
| Re: NG: bring_to_front doesn't always work [message #91810 is a reply to message #91807] |
Sun, 30 August 2015 15:13 |
dg86
Messages: 118
Registered: September 2012
|
Senior Member |
|
|
On Sunday, August 30, 2015 at 1:43:32 PM UTC-4, wtci...@gmail.com wrote:
> On Wednesday, August 6, 2014 at 12:50:06 PM UTC-7, David Grier wrote:
>> On Wednesday, August 6, 2014 1:05:34 PM UTC-4, Chris Torrence wrote:
>>> Hi David,
>>>
>>>
>>>
>>> I think this might be a bug in the Mesa OpenGL software-rendering library. Can you check your IDL preferences and see if you have "software" rendering enabled? If you do, can you switch it to "hardware" rendering and see if the problem goes away?
>>>
>>>
>>>
>>> -Chris
>>
>> Dear Chris,
>>
>> You may be right about the culprit being Mesa OpenGL.
>> I usually run IDL from emacs (or the command line) rather than from the Workbench, and so have
>> not fiddled with the settings for the graphics backend. I just fired up the IDL 8.3 Workbench and
>> tried to run my example script. It worked as usual with software rendering enabled, but not
>> at all with hardware rendering enabled, instead emitting error messages such as
>>
>> % Graphics device not available: GL_COCOA.
>> % Attempt to destroy an object within its INIT method: <ObjHeapVar11153(GRAPHICSWIN)>.
>> % Execution halted at: $MAIN$
>>
>> So, hardware rendering appears not to work at all(!).
>>
>> I'm running IDL 8.3 under OS X 10.9.4 on a Macbook Pro.
>>
>> All the best,
>>
>> David
>
> Hello David,
>
> I just fixed my problem right after posting here. I followed the instruction here
> http://www.exelisvis.com/Support/HelpArticlesDetail/TabId/21 9/ArtMID/900/ArticleID/5294/5294.aspx
>
> And follow this step
>
> 1.) Configure IDL to use Software Rendering.
> a.) You can change your IDL preference to use Software rendering via the IDL Workbench Preferences dialog. From the "IDL" select "Preferences...". On the left pane of the Preferences dialog, expand IDL and select Graphics, and then on the right choose the "Default rendering method for object graphics" setting for Software (1)). Click Apply and then OK. (This approach can be used even if running IDL in unlicensed demonstration mode.)
>
>
> Then the plotting issue within workbench is solved immediately.
>
> Good luck! Hope that helps!
It sounds like your experience is the same as mine. Even though object plots appear
to work OK under software rendering, it would be nice to have hardware rendering
working, particularly for interactive graphics and demos. More to the point, hardware
rendering should not error out.
Does anyone know if this has been fixed under 8.5?
(I haven't had a chance to upgrade yet.)
TTFN,
David
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
