[RQt-devel] possible bug in qtbase

[Michael Lawrence]

On Tue, Sep 20, 2011 at 9:48 PM, Michael Lawrence <michafla at gene.com> wrote:

>
>
> On Tue, Sep 20, 2011 at 7:40 PM, Deepayan Sarkar <
> deepayan.sarkar at gmail.com> wrote:
>
>> On Wed, Sep 21, 2011 at 3:20 AM, Michael Lawrence
>> <lawrence.michael at gene.com> wrote:
>> >
>> >
>> > On Tue, Sep 20, 2011 at 12:03 PM, Deepayan Sarkar
>> > <deepayan.sarkar at gmail.com> wrote:
>> >>
>> >> On Tue, Sep 20, 2011 at 8:55 PM, Michael Lawrence
>> >> <lawrence.michael at gene.com> wrote:
>> >> > Hi Deepayan,
>> >> >
>> >> > Nice to hear you are back into the Qt stuff. I can indeed reproduce
>> >> > this.
>> >> > But not anymore, because I've fixed it.
>> >>
>> >> Thanks, I can confirm the fix.
>> >>
>> >> I've decided to try out a different approach, managing the layout in R
>> >> as much as possible, and target multiple backends. I'm initially
>> >> experimenting with QGraphicsView/Scene, and now I'm getting much
>> >> further with that thanks to your fix. At some point I'll start bugging
>> >> you about qtpaint as well.
>> >>
>> >
>> > You might want to check out anypaint in the GGobi github. Gabriel Becker
>> > (DTL's student) has been doing a lot of work on generic (pure R, backend
>> > agnostic) implementations of things like layout. He's implementing
>> anypaint
>> > against HTML5/JS in Firefox, via RFirefox. I need to make sure that he
>> is
>> > committing his stuff back into github.
>>
>> Seems mostly notImplemented() calls right now.
>>
>>
> Right, it's just the abstraction. Gabe's firepaint package implements it
> for RFirefox. qtpaint will implement it for Qt.
>
>
>>  >> I think there are still problems lurking around. Here is a protection
>> >> bug: This gives an error because the gc() causes view$scene() to go
>> >> away.
>> >>
>> >> ----
>> >> library(qtbase)
>> >>
>> >> view <- Qt$QGraphicsView()
>> >> view$size <- qsize(600, 600)
>> >> view$setScene(Qt$QGraphicsScene())
>> >> ## class(view$scene())
>> >> gc()
>> >> view$scene() # NULL
>> >> view$scene()$clear()
>> >> ----
>> >>
>> >> If I uncomment the 'class(view$scene())' then things are OK.
>> >>
>> >
>> > This is just Qt. Neither R nor QGraphicsView keep a reference to the
>> scene.
>> > This is why qtpaint sets the parent of the scene to the view, if it does
>> not
>> > already have a parent.
>>
>> So having an R reference like so
>>
>> scene <- Qt$QGraphicsScene()
>> view$setScene(scene)
>>
>> should be safe?
>>
>>
> Yes, but I would recommend setting the parent, so that you do not need to
> worry about the R reference. That's sensible as long as you have a single
> view.
>
>
>> >> In a more realistic example involving QGraphicsScene (that I haven't
>> >> been able to simplify yet), having a gc() keeps things sane, and not
>> >> having it leads to errors similar to the ones before, e.g.,
>> >>
>> >> Error in qinvokeStatic(cl, basename, ...) :
>> >>  Expected an instance of type 'QColor', not 'QGraphicsLineItem'
>> >> Calls: print ... is -> qbrush -> <Anonymous> -> qinvokeStatic -> .Call
>> >>
>> >
>> > Looking forward to that simplified example.
>>
>> Here goes. Adding the gc() makes the whole thing work fine. The
>> trivial qpen() call is required.
>>
>>
> Thanks a lot. Will look at this.
>
>
>> #----
>> library(qtbase)
>>
>> v <- Qt$QGraphicsView()
>> v$size <- qsize(300, 300)
>> scene <- Qt$QGraphicsScene()
>> v$setScene(scene)
>> v$show()
>>
>> doplot <- function(view, scene)
>> {
>>    ## gc()
>>    scene$clear()
>>    x <- runif(2, 50, 250)
>>    scene$addEllipse(x[1], x[2], 10, 10, qpen())
>>    Sys.sleep(0.01)
>> }
>>
>>
The issue is that scene$clear() frees all objects, including the ellipse,
but since Qt constructed the QGraphicsEllipseItem, we have no way of knowing
that it has been freed, and so we cannot clear the pointer out of the hash.
The fix yesterday made it so that if the R object was garbage collected, the
pointer would be cleared in this situation. It may be that we can get away
without adding such pointers to the hash at all, i.e., we would create a new
wrapper object every time we see them. That will take a lot of thought
though about the myriad of consequences.

Please stand by.

Michael



> niter <- 0L
>> while (TRUE)
>> {
>>    doplot(view = v, scene = scene)
>>    niter <- niter + 1
>>    cat(niter, fill = TRUE)
>> }
>> #----
>>
>> I'm usually getting an error within 10 iterations.
>>
>> -Deepayan
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/qtinterfaces-devel/attachments/20110921/973e966c/attachment.htm>