Bug 101326

Summary:	gallium/wgl: Allow context creation without prior SetPixelFormat()
Product:	Mesa	Reporter:	frank.richter
Component:	Other	Assignee:	mesa-dev
Status:	RESOLVED FIXED	QA Contact:	mesa-dev
Severity:	normal
Priority:	medium
Version:	17.1
Hardware:	Other
OS:	Windows (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	Patch: Allow context creation without prior SetPixelFormat()

Description frank.richter 2017-06-07 09:21:27 UTC

Created attachment 131764 [details] [review]
Patch: Allow context creation without prior SetPixelFormat()

Currently, when creating a context without having called SetPixelFormat() on the DC earlier, context creation fails.
However, looking at stw_make_current(), the intention there is to support that scenario; there, if the pixel format wasn't set, that function falls back to a default.
So it looks like context creation should work as well.
Attached patch does that by using pretty much the same logic as stw_make_current().

Comment 1 Brian Paul 2017-06-08 20:12:04 UTC

I may not have time to look at this for a few days.  But one question: did you find this because a particular app is working differently with Mesa than NVIDIA/AMD/Intel?  I guess I'd like to hear more background info about this.

Comment 2 frank.richter 2017-06-08 21:51:37 UTC

I'm trying to coerce a Chromium-based browser component to render WebGL using an llvmpipe Mesa.

At one point during initialization, it creates a short-lived context just to obtain some function addresses. It wants to create a context on the display DC, which apparently has no pixel format set - or at least a 'framebuffer' can't be determined.

If that early context creation fails desktop GL, if requested, won't be used and features requiring it disabled.

FWIW, Chrome makes use of NVIDIA's desktop GL when forced to do so, presumably that particular context creation succeeds there.

Comment 3 Brian Paul 2017-06-09 13:54:23 UTC

Thanks for the info.  The patch looks good.  I'll push it soon with minor reformatting.

Comment 4 Brian Paul 2017-06-09 14:55:20 UTC

Patch 0ef39e588f92236f9e2fb1909a314c7eb70db8c2 pushed.  Thanks, Frank.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.