search for: rf_addx11device

...icated across all(?) graphics devices. Paul On 28/04/19 11:39 AM, peter dalgaard wrote: > I had a look at the current code, and AFAICT it has essentially the same structure as it did back then. I think it may have finally dawned upon me what the issue really is: > > The logic is that in Rf_addX11Device, we have > > if (!X11DeviceDriver(dev, display, width, height, > ps, gamma, colormodel, maxcubesize, > bgcolor, canvascolor, sfonts, res, > xpos, ypos, title, useCairo, antialias, fami...

...X11 still segfaults". > >------------>> >..... >Gah. I've been too tired today. Why did that take me so long? > >The culprit seems to be > >R_ProcessEvents((void*) NULL) > >in newX11DeviceDriver > >This gets called *before* this stuff at the end of Rf_addX11Device > > dd = GEcreateDevDesc(dev); > addDevice((DevDesc*) dd); > initDisplayList((DevDesc*) dd); > >and it is that "dd" that gets called by Rf_playDisplayList. Removing >the offending line stops the segfaulting, seemingly with no ill >effects. > >I'm not real...

...gt; >> Paul >> >> On 28/04/19 11:39 AM, peter dalgaard wrote: >>> I had a look at the current code, and AFAICT it has essentially the same structure as it did back then. I think it may have finally dawned upon me what the issue really is: >>> The logic is that in Rf_addX11Device, we have >>> if (!X11DeviceDriver(dev, display, width, height, >>> ps, gamma, colormodel, maxcubesize, >>> bgcolor, canvascolor, sfonts, res, >>> xpos, ypos, title, use...

I had a look at the current code, and AFAICT it has essentially the same structure as it did back then. I think it may have finally dawned upon me what the issue really is: The logic is that in Rf_addX11Device, we have if (!X11DeviceDriver(dev, display, width, height, ps, gamma, colormodel, maxcubesize, bgcolor, canvascolor, sfonts, res, xpos, ypos, title, useCairo, antialias, family)) { free(dev)...

...raphics devices. > > Paul > > On 28/04/19 11:39 AM, peter dalgaard wrote: >> I had a look at the current code, and AFAICT it has essentially the same structure as it did back then. I think it may have finally dawned upon me what the issue really is: >> The logic is that in Rf_addX11Device, we have >> if (!X11DeviceDriver(dev, display, width, height, >> ps, gamma, colormodel, maxcubesize, >> bgcolor, canvascolor, sfonts, res, >> xpos, ypos, title, useCairo, antialias...

I don't recall exactly what I did 18 years ago eiher and I likely don't have the time to dig into the archives and reconstruct. I can imagine that the issue had to do with the protocol around creating and mapping windows. Presumably the segfault comes from looking for events on a window that hasn't been created yet, or has already been destroyed, leading to a NULL reference somewhere.

...-core November 29, 2001. Part of thread "X11 still segfaults". ------------>> ..... Gah. I've been too tired today. Why did that take me so long? The culprit seems to be R_ProcessEvents((void*) NULL) in newX11DeviceDriver This gets called *before* this stuff at the end of Rf_addX11Device dd = GEcreateDevDesc(dev); addDevice((DevDesc*) dd); initDisplayList((DevDesc*) dd); and it is that "dd" that gets called by Rf_playDisplayList. Removing the offending line stops the segfaulting, seemingly with no ill effects. I'm not really sure what the use of that line ever...

In R-1.5.0pre (2002-04-08) on Solaris 2.6, the window that X11() creates has a title like: R Graphics: Device 2 (ACTIVE) o iyeP )( y except the funny characters at the end have umlauts and other accents (i.e. extended ASCII characters), and they may be different each time X11() is invoked. There is no loss of functionality; it just looks a little ugly. I saw this behavior in R-1.3.?, it