Comments (6)
diff --git a/example/sdl-imageviewer/sdl-imageviewer.cc b/example/sdl-imageviewer/sdl-imageviewer.cc
index 6d2b0fec..76819716 100644
--- a/example/sdl-imageviewer/sdl-imageviewer.cc
+++ b/example/sdl-imageviewer/sdl-imageviewer.cc
@@ -229,6 +229,10 @@ bool g_load_via_sdl_image = false;
bool //
draw(SDL_Window* window) {
SDL_Surface* ws = SDL_GetWindowSurface(window);
+ if (!ws) {
+ fprintf(stderr, "draw: SDL_GetWindowSurface(): %s\n", SDL_GetError());
+ return false;
+ }
SDL_FillRect(ws, NULL, SDL_MapRGB(ws->format, 0x00, 0x00, 0x00));
if (g_image) {
SDL_BlitSurface(g_image, NULL, ws, NULL);
gives me the somewhat expected:
draw: SDL_GetWindowSurface(): Unknown window pixel format
from wuffs.
SDL can be made to work in the following manner, which even seems to be an acceptable patch as-is:
diff --git a/example/sdl-imageviewer/sdl-imageviewer.cc b/example/sdl-imageviewer/sdl-imageviewer.cc
index 6d2b0fec..1464c94c 100644
--- a/example/sdl-imageviewer/sdl-imageviewer.cc
+++ b/example/sdl-imageviewer/sdl-imageviewer.cc
@@ -229,6 +229,15 @@ bool g_load_via_sdl_image = false;
bool //
draw(SDL_Window* window) {
SDL_Surface* ws = SDL_GetWindowSurface(window);
+ if (!ws) {
+ SDL_Renderer *r = SDL_CreateRenderer(window, -1, 0);
+ SDL_Texture *texture = SDL_CreateTextureFromSurface(r, g_image);
+ SDL_RenderCopy(r, texture, nullptr, nullptr);
+ SDL_RenderPresent(r);
+ SDL_DestroyTexture(texture);
+ SDL_DestroyRenderer(r);
+ return true;
+ }
SDL_FillRect(ws, NULL, SDL_MapRGB(ws->format, 0x00, 0x00, 0x00));
if (g_image) {
SDL_BlitSurface(g_image, NULL, ws, NULL);
from wuffs.
Feel free to close my issue once SDL works (just handle the failing SDL_GetWindowSurface
), XCB rejected my attempts at debugging, and it's a horrible mess all around.
from wuffs.
Thanks for the bug report. Can you copy/paste the output of xdpyinfo
?
Or, if that's too large, perhaps xdpyinfo | head -n 100
?
System: Arch Linux, X11 with DefaultDepth 30
Just double-checking... is it really 30, not 32?
from wuffs.
It's just 10-bit colour. xdpyinfo.log doesn't contain alpha, so it isn't all that useful. This information is in pixelformats, not visuals.
Here is an XGB image viewer for a known-to-work approach, with XRender scaling, although it's set up to require the depth--you could have two serialising functions, one for ARGB32, another for RGB30.
from wuffs.
Coming back with randomly acquired knowledge. The display issue with the XCB demo is trivial: DecodeImageCallbacks::SelectPixfmt
virtual-defaults to WUFFS_BASE__PIXEL_FORMAT__BGRA_PREMUL
, and the xcb_image_t
is hardcoded to use s->root_depth
and completely disregards the Visual. The XRender extension could be used to resolve the difference within X.org, similarly to the way it's used in that Go code--this is the simplest fix, together with the SDL workaround.
The crash is due to XCB_CONN_CLOSED_REQ_LEN_EXCEED:
maximum request size: 16777212 bytes
which leaves shared memory or incremental uploads. I thought BIG-REQUESTS would help, but no.
from wuffs.
Related Issues (20)
- print-image-metadata script can go into an infinite loop
- Slow f64 parsing HOT 13
- RGB/BGR 16 bit treated like RGBA/BGRA? HOT 1
- OSS-Fuzz issue 59018 HOT 1
- [JPEG] unsupported DQT after SOF markers HOT 1
- OSS-Fuzz issue 59182 HOT 1
- OSS-Fuzz issue 59540 HOT 1
- OSS-Fuzz issue 59966 HOT 1
- A question regarding auxiliary C++ API HOT 4
- What is the status of version 0.3? HOT 3
- Empty slice manipulation triggers UBSAN by offsetting from a null pointer. HOT 2
- error: conversion to ‘uint32_t’ {aka ‘unsigned int’} from ‘int’ may change the sign of the result HOT 3
- OSS-Fuzz issue 66816 HOT 1
- PNG's are stored in RGB order but Wuffs returns BGR/BGRA? HOT 1
- Decode PNG with gray+alpha as 2 channels (i.e. YA not BGRA) HOT 5
- Warning about always true comparison of integers HOT 1
- std/crc64 doesn't build for 32-bit x86 HOT 1
- Allowing LA and RGBA PNGs with a tRNS chunk HOT 2
- How to get the correct 'transparency' value in the DecodeImage API? HOT 2
- wuffs 0.4 significantly slower than 0.3 decoding PNGs HOT 27
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wuffs.