WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
62318
Avoid always binding FBO 0 implicitly when deleting FBO in DrawingBuffer code because it invalidates Ganesh's cache of the current FBO.
https://bugs.webkit.org/show_bug.cgi?id=62318
Summary
Avoid always binding FBO 0 implicitly when deleting FBO in DrawingBuffer code...
Brian Salomon
Reported
2011-06-08 13:59:25 PDT
Don't bind aframebuffer before deleting it in DrawingBuffer::clear()
Attachments
Patch
(1.28 KB, patch)
2011-06-08 14:52 PDT
,
Mike Reed
no flags
Details
Formatted Diff
Diff
Patch
(1.51 KB, patch)
2011-06-08 15:17 PDT
,
Brian Salomon
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Mike Reed
Comment 1
2011-06-08 14:52:18 PDT
Created
attachment 96487
[details]
Patch
James Robinson
Comment 2
2011-06-08 14:57:29 PDT
Comment on
attachment 96487
[details]
Patch Could you expand on how this leads to a crash? Binding before deleting is weird, but it shouldn't be harmful unless there is a bug somewhere else.
Brian Salomon
Comment 3
2011-06-08 15:02:20 PDT
Deleting the bound FBO implicitly binds FBO 0. This confuses Ganesh which thinks it knows the currently bound FBO. This isn't a fix-all for coordinating GL state changes between DrawingBuffer and Ganesh. But it is a simple low risk change that fixes a M13 blocker.
James Robinson
Comment 4
2011-06-08 15:04:02 PDT
Comment on
attachment 96487
[details]
Patch I think you need to do the same thing on line 87. Are you sure that this codepath is never hit with the drawingbuffer's m_fbo already bound?
James Robinson
Comment 5
2011-06-08 15:06:58 PDT
(In reply to
comment #3
)
> Deleting the bound FBO implicitly binds FBO 0. This confuses Ganesh which thinks it knows the currently bound FBO. > > This isn't a fix-all for coordinating GL state changes between DrawingBuffer and Ganesh. But it is a simple low risk change that fixes a M13 blocker.
OK, so it sounds like the real bug here is that DrawingBuffer::clear() changes the currently bound framebuffer, and it shouldn't? Could you update the bug title + ChangeLog text to indicate that's what is going on? It seems pretty fragile to depend on this function not changing the current framebuffer binding...
Brian Salomon
Comment 6
2011-06-08 15:17:15 PDT
Created
attachment 96491
[details]
Patch
Brian Salomon
Comment 7
2011-06-08 15:22:04 PDT
(In reply to
comment #4
)
>(From update of
attachment 96487
[details]
) >I think you need to do the same thing on line 87.
Done in the latest patch.
>Are you sure that this codepath is never hit with the drawingbuffer's m_fbo >already bound?
In that case we're actually OK. The Gr object that wraps the DrawingBuffer's FBO is destroyed which causes Gr to invalidate its cache of the currently bound FBO. (In reply to
comment #5
)
> OK, so it sounds like the real bug here is that DrawingBuffer::clear() changes the currently bound framebuffer, and it shouldn't? Could you update the bug title + ChangeLog text to indicate that's what is going on? >
Yup, done in the latest patch.
> It seems pretty fragile to depend on this function not changing the current framebuffer binding...
I agree it is fragile. There will be a more robust fix for M14+.
James Robinson
Comment 8
2011-06-08 15:35:12 PDT
Comment on
attachment 96491
[details]
Patch Seems OK
Brian Salomon
Comment 9
2011-06-08 15:40:47 PDT
(In reply to
comment #8
)
> (From update of
attachment 96491
[details]
) > Seems OK
Thanks! I forgot to set commit:? after I uploaded.
WebKit Review Bot
Comment 10
2011-06-08 16:25:50 PDT
Comment on
attachment 96491
[details]
Patch Clearing flags on attachment: 96491 Committed
r88403
: <
http://trac.webkit.org/changeset/88403
>
WebKit Review Bot
Comment 11
2011-06-08 16:25:54 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug