I compiled latest trunk with the following: -DPORT=GTK -DUSE_GSTREAMER_GL=ON -DENABLE_GLES2=ON -DENABLE_ACCELERATED_2D_CANVAS=OFF -DUSE_SYSTEM_MALLOC=ON -DENABLE_X11_TARGET=OFF -DENABLE_MINIBROWSER=ON but webkit does not render any pages, local or over the network, either with MiniBrowser or Epiphany. Screenshot: http://imgur.com/a/tOqJZ
Could you try again with WebKitGTk+ 2.14.0 (or current trunk)?
I tried with 2.14.1. Indeed, on Wayland the area in MiniBrowser where the page should go remains blank/gray. Right-clicking in that very area, however, brings up a context menu corresponding to the supposedly-loaded webpage.
My compile options were as follows: cmake -DPORT=GTK -DCMAKE_BUILD_TYPE=Release -DENABLE_ACCESSIBILITY=OFF -DENABLE_CHANNEL_MESSAGING=OFF -DENABLE_CSS3_TEXT=ON -DENABLE_GEOLOCATION=OFF -DENABLE_INTROSPECTION=OFF -DENABLE_FTPDIR=ON -DENABLE_MEDIA_SOURCE=ON -DENABLE_MINIBROWSER=ON -DENABLE_NOTIFICATIONS=OFF -DUSE_LD_GOLD=OFF -DUSE_LIBHYPHEN=OFF -DUSE_LIBNOTIFY=OFF -DENABLE_CREDENTIAL_STORAGE=OFF -DENABLE_SPELLCHECK=OFF -DCMAKE_INSTALL_PREFIX="$HOME/local" -DENABLE_OPENGL=ON -DENABLE_GLES2=ON -DENABLE_WEB_REPLAY=ON -DENABLE_WEB_ANIMATIONS=ON -DENABLE_PLUGIN_PROCESS_GTK2=OFF ..
WebKitGTk+ 2.14.0 and 2.14.1 still have this issue (tested the debian armhf packages from stretch and sid). It looks like the pages are "loaded", but nothing gets rendered. It's not just the pages, but nothing gets rendered - e.g. I tried "Inspect Element" and nothing happened visually, the page remains blank.
(In reply to comment #4) > WebKitGTk+ 2.14.0 and 2.14.1 still have this issue (tested the debian armhf > packages from stretch and sid). > It looks like the pages are "loaded", but nothing gets rendered. It's not > just the pages, but nothing gets rendered - e.g. I tried "Inspect Element" > and nothing happened visually, the page remains blank. Can you try after export his environment variable? export WEBKIT_DISABLE_COMPOSITING_MODE=1 Does it make any difference?
(In reply to comment #5) > Can you try after export his environment variable? > > export WEBKIT_DISABLE_COMPOSITING_MODE=1 > > Does it make any difference? With WEBKIT_DISABLE_COMPOSITING_MODE=1 pages do get rendered. There are however issues e.g. when playing videos, but I guess that's to be expected.
(In reply to comment #6) > (In reply to comment #5) > > Can you try after export his environment variable? > > > > export WEBKIT_DISABLE_COMPOSITING_MODE=1 > > > > Does it make any difference? > > With WEBKIT_DISABLE_COMPOSITING_MODE=1 pages do get rendered. There are > however issues e.g. when playing videos, but I guess that's to be expected. I guess you are trying to run webkit under wayland, right? Can you answer: 1) What GPU do you have? 2) What OpenGL drivers (and version) are you using? 3) Is EGL working on your wayland environment? For example, can you run the test program /usr/lib/weston/weston-simple-egl and see the triangle rotating? 4) Can you try this program http://sprunge.us/FOIe and paste the output here?: $ wget http://sprunge.us/FOIe -O waylandes2info.c $ gcc $(pkg-config --cflags --libs wayland-client egl glesv2 wayland-egl wayland-server) waylandes2info.c -o waylandes2info $ ./waylandes2info
(In reply to comment #7) > (In reply to comment #6) > > With WEBKIT_DISABLE_COMPOSITING_MODE=1 pages do get rendered. There are > > however issues e.g. when playing videos, but I guess that's to be expected. > > I guess you are trying to run webkit under wayland, right? > > Can you answer: > > > 1) What GPU do you have? > > 2) What OpenGL drivers (and version) are you using? > > 3) Is EGL working on your wayland environment? For example, can you run the > test program /usr/lib/weston/weston-simple-egl and see the triangle rotating? > > 4) Can you try this program http://sprunge.us/FOIe and paste the output > here?: > > $ wget http://sprunge.us/FOIe -O waylandes2info.c > $ gcc $(pkg-config --cflags --libs wayland-client egl glesv2 wayland-egl > wayland-server) waylandes2info.c -o waylandes2info > $ ./waylandes2info Thanks for the quick answer. 1) GPU is Mali T628, on Exynos5422 ARM platform (Odroid XU4) 2) OpenGL-ES 3.1 3)Yes, EGL is working, apps like wayland-simple-egl, glmark2-es2-wayland work, and heavier apps like gnome-maps, kodi work too. gnome-shell and weston are also EGL-accelerated via GBM(KMS). 4) here's the output from waylandes2info: EGL_VERSION = 1.4 Midgard-"r10p0-00rel0" EGL_VENDOR = ARM EGL_EXTENSIONS = EGL_WL_bind_wayland_display EGL_KHR_partial_update EGL_KHR_config_attribs EGL_KHR_image EGL_KHR_image_base EGL_KHR_fence_sync EGL_KHR_wait_sync EGL_KHR_gl_colorspace EGL_KHR_get_all_proc_addresses EGL_IMG_context_priority EGL_ARM_pixmap_multisample_discard EGL_KHR_gl_texture_2D_image EGL_KHR_gl_renderbuffer_image EGL_KHR_create_context EGL_KHR_surfaceless_context EGL_KHR_gl_texture_cubemap_image EGL_EXT_create_context_robustness EGL_KHR_cl_event2 EGL_CLIENT_APIS = OpenGL_ES GL_VERSION: OpenGL ES 3.1 v1.r10p0-00rel0.96536f95341f755422ab626cb4211af7 GL_RENDERER: Mali-T628 GL_EXTENSIONS: GL_ARM_rgba8, GL_ARM_mali_shader_binary, GL_OES_depth24, GL_OES_depth_texture, GL_OES_depth_texture_cube_map, GL_OES_packed_depth_stencil, GL_OES_rgb8_rgba8, GL_EXT_read_format_bgra, GL_OES_compressed_paletted_texture, GL_OES_compressed_ETC1_RGB8_texture, GL_OES_standard_derivatives, GL_OES_EGL_image, GL_OES_EGL_image_external, GL_OES_EGL_sync, GL_OES_texture_npot, GL_OES_vertex_half_float, GL_OES_required_internalformat, GL_OES_vertex_array_object, GL_OES_mapbuffer, GL_EXT_texture_format_BGRA8888, GL_EXT_texture_rg, GL_EXT_texture_type_2_10_10_10_REV, GL_OES_fbo_render_mipmap, GL_OES_element_index_uint, GL_EXT_shadow_samplers, GL_OES_texture_compression_astc, GL_KHR_texture_compression_astc_ldr, GL_KHR_texture_compression_astc_hdr, GL_KHR_debug, GL_EXT_occlusion_query_boolean, GL_EXT_disjoint_timer_query, GL_EXT_blend_minmax, GL_EXT_discard_framebuffer, GL_OES_get_program_binary, GL_OES_texture_3D, GL_EXT_texture_storage, GL_EXT_multisampled_render_to_texture, GL_OES_surfaceless_context, GL_OES_texture_stencil8, GL_EXT_shader_pixel_local_storage, GL_ARM_shader_framebuffer_fetch, GL_ARM_shader_framebuffer_fetch_depth_stencil, GL_ARM_mali_program_binary, GL_EXT_sRGB, GL_EXT_sRGB_write_control, GL_EXT_texture_sRGB_decode, GL_KHR_blend_equation_advanced, GL_KHR_blend_equation_advanced_coherent, GL_OES_texture_storage_multisample_2d_array, GL_OES_shader_image_atomic, GL_EXT_robustness, GL_EXT_texture_border_clamp, GL_OES_texture_border_clamp, GL_EXT_texture_cube_map_array, GL_OES_texture_cube_map_array, GL_OES_sample_variables, GL_OES_sample_shading, GL_OES_shader_multisample_interpolation, GL_EXT_shader_io_blocks, GL_OES_shader_io_blocks, GL_EXT_gpu_shader5, GL_OES_gpu_shader5, GL_EXT_texture_buffer, GL_OES_texture_buffer, GL_EXT_copy_image, GL_OES_copy_image, GL_ARM_packed_arithmetic Here's an older grab that shows weston-simple-egl, webkit-gtk 2.12 (epiphany) and glmark2-es2-wayland working: https://www.youtube.com/watch?v=AkSgm4JF81U. I hope to get to use USE_GSTREAMER_GL on 2.14, since in 2.12 it was not ready.
I think this is the same problem as bug #163595, see comment 5 there for an explanation of what I think the problem is. Could any of you try falling back to glReadPixels?
Created attachment 292995 [details] Do not use gdk_cairo_draw_from_gl with GLES2 Could you guys try this patch?
(In reply to comment #10) > Created attachment 292995 [details] > Do not use gdk_cairo_draw_from_gl with GLES2 > > Could you guys try this patch? Hi, I am trying the patch. 1) unrelated issue, I have to add -fpermissive flag when compiling this file: Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.cpp: In member function ‘bool WebCore::MediaPlayerPrivateGStreamerBase::ensureGstGLContext()’: Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.cpp:247:63: warning: passing ‘const WebCore::PlatformDisplay’ as ‘this’ argument discards qualifiers [-fpermissive] GLContext* webkitContext = sharedDisplay.sharingGLContext(); ^ (I use -DUSE_GSTREAMER_GL=ON) 2) I get: EGLDisplayInitialization failed. I am debugging to see if it gets the correct display...
Just to add some more details about the error: The error comes from Source/WebCore/platform/graphics/PlatformDisplay.cpp - initializeEGLDisplay() The code path goes through the correct chain of functions from what I can tell, it is using the WaylandPlatform code, and it is the eglInitialize function that fails although m_eglDisplay is not EGL_NO_DISPLAY. I know eglInitialize is platform specific, however it's the 3rd eglDisplay that gets initialized where this issue occurs; the first 2 are initialized successfully and added to the eglDisplays list. Any idea why it fails the 3rd time, and what are the previous 2 eglDisplays (that were initialized correctly) used for?
One more update - error thrown by eglInitialize is: EGL_NOT_INITIALIZED: is generated if display cannot be initialized.
Another note: eglInitialize fails when it's running with the display returned by wl_display_connect from Source/WebKit2/WebProcess/WebPage/gtk/AcceleratedSurfaceWayland.cpp; I haven't figured out yet where those other 2 calls are coming from, but it's not from AcceleratedSurfaceWayland.cpp.
Some new update: With -DENABLE_THREADED_COMPOSITOR=OFF non-EGL pages (e.g. google.com) render ok - there are only the 2 calls for eglInitialize, none of them coming from WebPage/gtk/AcceleratedSurfaceWayland.cpp. I am pretty sure with -DENABLE_THREADED_COMPOSITOR=ON those pages were not rendered. But once a page with video or WebGL loads (heck, even yahoo.com), the page dies with eglInitialize failure. Can this be a multi-threaded issue (because the drivers doesn't likes it?). Then again, the call to initialize from WebPage/gtk/AcceleratedSurfaceWayland.cpp still ends up failing in eglInitialize :( PS: I also tried replacing eglGetDisplay with eglGetDisplayEXT(EGL_PLATFORM_WAYLAND_KHR) but the behaviour was exactly the same... (I did this because my drivers don't like eglGetDisplay for EGL_PLATFORM_GBM_KHR, but they do like eglGetDisplayEXT).
And another update: I tested weston with wayland backend, and weston-simple-egl also fails at eglInitialize. So it looks like it might be an issue with eglBindWaylandDisplayWL in the ARM drivers, and this can be closed. I reported the issue on ARM community, although i don't expect a reply from ARM too soon :(
(In reply to comment #16) > And another update: > > I tested weston with wayland backend, and weston-simple-egl also fails at > eglInitialize. > So it looks like it might be an issue with eglBindWaylandDisplayWL in the > ARM drivers, and this can be closed. > I reported the issue on ARM community, although i don't expect a reply from > ARM too soon :( What weston backend where you using before? X11?
OK then