Reproducible on a MacBook Pro Retina with NVIDIA GPU. about:gpu follows.

I'm not immediately sure what's going on. Would have to debug into the texture uploading code to see if the image's being decoded at the correct size, etc.

The problem's not that the app is failing to flip the texture vertically; it's symmetric vertically.


Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Hardware accelerated
Rasterization: Software only. Hardware acceleration disabled
Video Decode: Hardware accelerated
Video Encode: Hardware accelerated
VPx Video Decode: Hardware accelerated
WebGL: Hardware accelerated
Driver Bug Workarounds
adjust_src_dst_region_for_blitframebuffer
decode_encode_srgb_for_generatemipmap
disable_framebuffer_cmaa
disable_multimonitor_multisampling
get_frag_data_info_bug
needs_offscreen_buffer_workaround
pack_parameters_workaround_with_pack_buffer
regenerate_struct_names
scalarize_vec_and_mat_constructor_args
set_zero_level_before_generating_mipmap
unfold_short_circuit_as_ternary_operation
unpack_alignment_workaround_with_unpack_buffer
unpack_overlapping_rows_separately_unpack_buffer
use_intermediary_for_copy_texture_image
use_shadowed_tex_level_params
use_unused_standard_shared_blocks
Problems Detected
Work around a bug in offscreen buffers on NVIDIA GPUs on Macs: 89557
Applied Workarounds: needs_offscreen_buffer_workaround
Multisampling is buggy on OSX when multiple monitors are connected: 237931
Applied Workarounds: disable_multimonitor_multisampling
Unfold short circuit on Mac OS X: 307751
Applied Workarounds: unfold_short_circuit_as_ternary_operation
Always rewrite vec/mat constructors to be consistent: 398694
Applied Workarounds: scalarize_vec_and_mat_constructor_args
Mac drivers handle struct scopes incorrectly: 403957
Applied Workarounds: regenerate_struct_names
glGenerateMipmap fails if the zero texture level is not set on some Mac drivers: 560499
Applied Workarounds: set_zero_level_before_generating_mipmap
Pack parameters work incorrectly with pack buffer bound: 563714
Applied Workarounds: pack_parameters_workaround_with_pack_buffer
Alignment works incorrectly with unpack buffer bound: 563714
Applied Workarounds: unpack_alignment_workaround_with_unpack_buffer
copyTexImage2D fails when reading from IOSurface on multiple GPU types.: 581777
Applied Workarounds: use_intermediary_for_copy_texture_image
Unpacking overlapping rows from unpack buffers is unstable on NVIDIA GL driver: 596774
Applied Workarounds: unpack_overlapping_rows_separately_unpack_buffer
Mac Drivers store texture level parameters on int16_t that overflow: 610153
Applied Workarounds: use_shadowed_tex_level_params
Limited enabling of Chromium GL_INTEL_framebuffer_CMAA: 535198
Applied Workarounds: disable_framebuffer_cmaa
glGetFragData{Location|Index} works incorrectly on Max: 638340
Applied Workarounds: get_frag_data_info_bug
Decode and encode before generateMipmap for srgb format textures on macosx: 634519
Applied Workarounds: decode_encode_srgb_for_generatemipmap
Insert statements to reference all members in unused std140/shared blocks on Mac: 618464
Applied Workarounds: use_unused_standard_shared_blocks
adjust src/dst region if blitting pixels outside read framebuffer on Mac: 644740
Applied Workarounds: adjust_src_dst_region_for_blitframebuffer
Accelerated rasterization has been disabled, either via blacklist, about:flags or the command line.
Disabled Features: rasterization
Version Information
Data exported	10/27/2016, 3:31:40 PM
Chrome version	Chrome/56.0.2901.0
Operating system	Mac OS X 10.11.6
Software rendering list version	11.18
Driver bug list version	9.12
ANGLE commit id	af7f301f6ba9
2D graphics backend	Skia/55 8bce117ff770f4778f496911b83f953a53907ed4
Command Line Args	Chrome Canary.app/Contents/MacOS/Google Chrome Canary --flag-switches-begin --flag-switches-end
Driver Information
Initialization time	68
In-process GPU	false
Sandboxed	true
GPU0	VENDOR = 0x10de, DEVICE= 0x0fe9 *ACTIVE*
GPU1	VENDOR = 0x8086, DEVICE= 0x0d26
Optimus	true
AMD switchable	false
Driver vendor	
Driver version	10.10.13 310.42.25f01
Driver date	
Pixel shader version	4.10
Vertex shader version	4.10
Max. MSAA samples	8
Machine model name	MacBookPro
Machine model version	11.3
GL_VENDOR	NVIDIA Corporation
GL_RENDERER	NVIDIA GeForce GT 750M OpenGL Engine
GL_VERSION	4.1 NVIDIA-10.10.13 310.42.25f01
GL_EXTENSIONS	GL_ARB_blend_func_extended GL_ARB_draw_buffers_blend GL_ARB_draw_indirect GL_ARB_ES2_compatibility GL_ARB_explicit_attrib_location GL_ARB_gpu_shader_fp64 GL_ARB_gpu_shader5 GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_occlusion_query2 GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_shader_subroutine GL_ARB_shading_language_include GL_ARB_tessellation_shader GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_cube_map_array GL_ARB_texture_gather GL_ARB_texture_query_lod GL_ARB_texture_rgb10_a2ui GL_ARB_texture_storage GL_ARB_texture_swizzle GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_vertex_attrib_64bit GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_depth_bounds_test GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_texture_compression_s3tc GL_EXT_texture_filter_anisotropic GL_EXT_texture_mirror_clamp GL_EXT_texture_sRGB_decode GL_APPLE_client_storage GL_APPLE_container_object_shareable GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_texture_range GL_ATI_texture_mirror_once GL_NV_texture_barrier
Disabled Extensions	
Window system binding vendor	
Window system binding version	
Window system binding extensions	
Direct rendering	Yes
Reset notification strategy	0x0000
GPU process crash count	0
Compositor Information
Tile Update Mode	Zero-copy
Partial Raster	Enabled
GpuMemoryBuffers Status
ATC	Software only
ATCIA	Software only
DXT1	Software only
DXT5	Software only
ETC1	Software only
R_8	GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT
RG_88	Software only
BGR_565	Software only
RGBA_4444	Software only
RGBX_8888	Software only
RGBA_8888	GPU_READ, SCANOUT
BGRX_8888	GPU_READ, SCANOUT
BGRA_8888	GPU_READ, SCANOUT, GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT
YVU_420	Software only
YUV_420_BIPLANAR	GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT
UYVY_422	GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT

The problem's not with the texture upload; it's with the sizing of the canvas. The application's not only uploading a huge texture (which is working fine) but also setting the WebGL canvas's width and height to that size, and using CSS to shrink it back down to 500 pixels wide. There is no guarantee that the WebGL canvas will be allocated at this size. The application needs to query the drawingBufferWidth and drawingBufferHeight attributes to know exactly the size of the backing store. There's no point in allocating the canvas this large; the downscaling will look awful.

Manually setting the canvas's width to 500 pixels, and setting the viewport appropriately looks fine. Revised test case attached. Closing as WontFix -- not a bug.

Deleted: crbug-659973.zip 2.7 KB

crbug-659973.zip 2.7 KB Download

You are right this has nothing to do with the texture size but is related to the WebGL canvas size. I found these two issues that seem to be related:

https://bugs.chromium.org/p/chromium/issues/detail?id=445542
https://bugs.chromium.org/p/chromium/issues/detail?id=399114

I'm not sure how to handle this problem if its not a bug, though. How do I reliably query the maximum possible drawing buffer size? I can set the initial size of the canvas to the size of the original image and then resize it according to the drawing buffer dimensions like this:

	canvas.width = 5200;
	canvas.height = 3400;
	canvas.width = gl.drawingBufferWidth;
	canvas.height = gl.drawingBufferHeight;

But then the drawing buffer dimensions decrease *again* and the problem still occurs.

There is the MAX_RENDERBUFFER_SIZE parameter but it reports 8192 on my machine so it's not reliable. Some site [1] advises:

"It is usual that renderbuffers are ok up to the size of a devices display. More may be supported, but is not guaranteed to be."

[1]: http://codeflow.org/entries/2013/feb/22/how-to-write-portable-webgl/#how-to-query-possible-sizes

I've attached an updated test case with a smaller texture but a large canvas size.

Deleted: crbug-659973.zip 9.1 KB

crbug-659973.zip 9.1 KB Download

There's no query for the maximum drawing buffer size. Chromium enforces some semi-arbitrary limits that should be enough for reasonable applications. Why are you trying to allocate a huge canvas? There is no reason to do so. You should generally allocate your WebGL canvas so that its pixels map 1:1 to device pixels -- see https://www.khronos.org/webgl/wiki/HandlingHighDPI -- and control your rendering yourself. You can of course allocate large textures, renderbuffers, etc. to be used during your rendering process.

This is more a question than a bug report. I suggest posting on the webgl-dev-list Google group with further questions.

I'm using an OpenLayers map so users can navigate large images. The WebGL rendering is used as a preprocessing step to apply filters (with glfx.js) to the original image. That's why I use a canvas with the same size than the original image. Maybe I'll process the image in tiles if it gets larger than the screen size.

Anyway, thanks for taking your time with this!

I'm not sure exactly how you're using glfx.js, but if you are reading back the rendering results with readPixels rather than expecting to display them on-screen, then you can allocate a framebuffer object, allocate a large texture, and attach that as the framebuffer object's color attachment. Then you can render your large image to that FBO and read back the results. This will give you a renderable surface of guaranteed size.

Thank you for the advice, that should be possible! I'll have to see if it can be implemented with glfx.js, though.