Closed GoogleCodeExporter closed 9 years ago
When loading cefpython homepage RenderHandler.GetScreenRect() is called 3
times, it is also called when going to Downloads page. When dropdown menu is
expanded there is a call to RenderHandler.GetViewRect(). I think that we need
to provide implemntations for these callbacks in panda3d example. There is also
RenderHandler.GetScreenPoint().
Original comment by czarek.t...@gmail.com
on 27 Dec 2012 at 4:38
A call to RenderHandler.GetViewRect() is made just before the crash, it is
probably critical to implement it.
Original comment by czarek.t...@gmail.com
on 27 Dec 2012 at 6:37
Did you try implementing these 3 callbacks?
Original comment by czarek.t...@gmail.com
on 29 Dec 2012 at 3:36
Yes i did, however implementations for some reason are never executed in my
case. Assertion kills app first.
My code:
def GetViewRect(self, browser, rect):
print 'GetViewRect'
width = self.texture.getXSize()
height = self.texture.getYSize()
rect.append(0)
rect.append(0)
rect.append(width)
rect.append(height)
return True
def GetScreenRect(self, browser, rect):
print 'GetScreenRect'
return self.GetViewRect(browser, rect)
def GetScreenPoint(self, browser, viewX, viewY, screenCoordinates):
print 'GetScreenPoint'
screenCoordinates.append(viewX)
screenCoordinates.append(viewY)
return True
P.S. this code is from my own app where web view covers whole screen
Original comment by roxaz...@gmail.com
on 29 Dec 2012 at 9:02
I've created a topic on CEF Forum regarding this matter:
http://magpcss.org/ceforum/viewtopic.php?f=6&t=10343
Original comment by czarek.t...@gmail.com
on 30 Dec 2012 at 4:27
I see now what is going, when you click on dropdown menu, the paintElementType
is PET_POPUP (normally PET_VIEW) and the buffer contains data for drawing only
popup widget (dropdown menu).
We probably need to call Browser->GetImage() to get the buffer with the
dropdown menu being drawn when paintElementType is PET_POPUP.
Original comment by czarek.t...@gmail.com
on 2 Jan 2013 at 11:24
We need to draw the popup widget ourselves by modyfiying the buffer.
Original comment by czarek.t...@gmail.com
on 2 Jan 2013 at 11:36
oh right, just as in my berkelium code!
i assume its best to be done in c++ for efficiency too right?
Original comment by roxaz...@gmail.com
on 3 Jan 2013 at 8:52
In OnPaint the dirtyRects have x=0, y=0 for PET_POPUP, how do we know where to
draw it? How does CEF know where we drew it, whether the menu expanded to the
top / bottom / left or right? How do we forward mouse click/move events on that
popup to CEF?
Original comment by czarek.t...@gmail.com
on 3 Jan 2013 at 2:38
By looking at my old berkelium-related code i see widgets having their own
buffers and changes being drawn to those buffers. That explains x and y being 0.
Later on they are drawn on main buffer after main window is drawn on that
buffer.
I do not recall any special requirements for event passing to widgets. To my
knowledge it was done automatically in berkelium so most likely it is the case
with CEF too.
Code im speaking of is one you already saw:
http://pastebox.it/file/fAGxcpGbXvu8fhDsaO6lcBEXgHk/8EEvDA.cpp
Original comment by roxaz...@gmail.com
on 3 Jan 2013 at 2:48
We will have to analyze cefclient sources as Marshall sugessts here:
http://magpcss.org/ceforum/viewtopic.php?p=15259#p15259
cefclient sources are here:
http://code.google.com/p/chromiumembedded/source/browse/branches/1271/cef1/tests
/cefclient/
What interests us is probably:
- clientplugin.cpp
http://code.google.com/p/chromiumembedded/source/browse/branches/1271/cef1/tests
/cefclient/clientplugin.cpp
- osrenderer.cpp
http://code.google.com/p/chromiumembedded/source/browse/branches/1271/cef1/tests
/cefclient/osrenderer.cpp
- osrplugin.cpp
http://code.google.com/p/chromiumembedded/source/browse/branches/1271/cef1/tests
/cefclient/osrplugin.cpp
- osrplugin_test.cpp
http://code.google.com/p/chromiumembedded/source/browse/branches/1271/cef1/tests
/cefclient/osrplugin_test.cpp
Original comment by czarek.t...@gmail.com
on 3 Jan 2013 at 9:58
Yup its pretty much what i said. :)
I started work on implementation of popup rendering. It is basically mimicking
whats in osrenderer.cpp.
Now i propose moving code that fills buffer with pixel data from
RenderHandler_OnPaint to ClientHandler::OnPaint. Main reason - its easier there
to store popup rect obtained from ClientHandler::OnPopupSize, and that rect is
needed in OnPaint callback to draw popup on image buffer. So
RenderHandler_OnPaint would become only a wrapper function like for example
RenderHandler_OnPopupShow.
What do you think? Maybe you have better alternative in mind?
Original comment by roxaz...@gmail.com
on 10 Jan 2013 at 11:15
We should not modify ClientHandler, like I said on the cefpython
group, any c++ code should go to cpp_utils/ directory. All methods
of RenderHandler have Browser object which has a method for storing
custom data (rect you mention) associated with this browser, see
SetUserData() & GetUserData():
http://code.google.com/p/cefpython/wiki/Browser
Remember also that the void* buffer passed to OnPaint() method is
read-only.
In PaintBuffer class (paint_buffer.pyx) we malloc our own buffer,
but it is free'd before GetString() method returns, for drawing
popups we need to store this buffer between OnPaint() calls. We
should extend PaintBuffer for drawing popups, also drawing of a
popup should be optional, we should not begin any drawing until
some method like GetString() is called on the PaintBuffer object.
It probably should not be allowed to use different mode or origin
when calling GetString() in subsequent OnPaint() calls.
Original comment by czarek.t...@gmail.com
on 10 Jan 2013 at 3:33
In CEF 3 Kivy OSR example SELECT boxes were fixed by injecting a javascript
boxes library on webpages, that transform normal <SELECT> elements into
javascript
ones. See this commit:
https://code.google.com/p/cefpython/source/detail?r=a9fd89cc746176806a542829e2a1
bdd484d8f0b6
Original comment by czarek.t...@gmail.com
on 18 Sep 2013 at 8:44
[deleted comment]
[deleted comment]
CEF 1 is deprecated.
Original comment by czarek.t...@gmail.com
on 10 Aug 2014 at 6:57
Original issue reported on code.google.com by
roxaz...@gmail.com
on 27 Dec 2012 at 4:25