Hi,
I have had a quick look. Although I'm not a big fan of the old OpenML
extension. It would be really nice if DRI drivers could be fixed to
get a proper glXWaitGL and friends. It still feels like the OpenML
extension does a little more than we really need. Since all DRI2
drivers seem to support
Below is a patch which fixes the visuals for me, it simply uses
glXWaitForSbcOML, falling back to glFinish if that's not supported.
Partway through coding this up, I was thinking that maybe listening
for damage events would be more natural. One reason: the current
code is probably imperfect for si
Re-adding wine-devel.
On Wed, Feb 8, 2012 at 2:42 PM, Brian Bloniarz wrote:
> On Wed, Feb 8, 2012 at 12:33 PM, Roderick Colenbrander
> wrote:
>>
>> On Wed, Feb 8, 2012 at 6:31 PM, Matteo Bruni
>> wrote:
>> > I'm not really such an expert in the area, but I think both (1) and
>> > (2) make sense
On Wed, Feb 8, 2012 at 6:31 PM, Matteo Bruni wrote:
> Il 08 febbraio 2012 18:19, Brian Bloniarz ha
> scritto:
>> Hi all,
>>
>> I could use a little help fixing a window lag and screen corruption
>> issue in SketchUp:
>> http://bugs.winehq.org/show_bug.cgi?id=25912
>> Long story short, I think th
Il 08 febbraio 2012 18:19, Brian Bloniarz ha scritto:
> Hi all,
>
> I could use a little help fixing a window lag and screen corruption
> issue in SketchUp:
> http://bugs.winehq.org/show_bug.cgi?id=25912
> Long story short, I think the implementation of OpenGL child rendering
> needs a small updat
Hi all,
I could use a little help fixing a window lag and screen corruption
issue in SketchUp:
http://bugs.winehq.org/show_bug.cgi?id=25912
Long story short, I think the implementation of OpenGL child rendering
needs a small update.
As a reminder, this is how an OpenGL child window is setup:
sta
Hello Chris Robinson,
A long time ago you wrote in
http://www.winehq.org/pipermail/wine-devel/2007-October/059550.html
that you got my example program running:
"If I force offscreen rendering and add the flag, the demo works."
Could you have a look at the following bug report and may explain how
On Tuesday 30 September 2008 02:11:17 am Florian Köberle wrote:
> A long time ago you wrote in
> http://www.winehq.org/pipermail/wine-devel/2007-October/059550.html
> that you got my example program running:
>
> "If I force offscreen rendering and add the flag, the demo works."
>
> Could you have a
Roderick Colenbrander a écrit :
>> I tested git version with solidworks, and now it's worse than with
>> previous chris patch :
>>
>> - quite slow, just like with composite patch
>> - highlighted lines offset, just like with composite patch
>> - GLXbaddrawable crash when opening multiple windows,
> I tested git version with solidworks, and now it's worse than with
> previous chris patch :
>
> - quite slow, just like with composite patch
> - highlighted lines offset, just like with composite patch
> - GLXbaddrawable crash when opening multiple windows, regression from
> the composite patc
I tested git version with solidworks, and now it's worse than with
previous chris patch :
- quite slow, just like with composite patch
- highlighted lines offset, just like with composite patch
- GLXbaddrawable crash when opening multiple windows, regression from
the composite patch, that allows
On Wednesday 03 October 2007 06:59:15 am Florian Köberle wrote:
> Hi
>
> I tried the Window with Button Demo from:
> http://bugs.winehq.org/attachment.cgi?id=5777
>
> The main window still overdraw the button.
>
> Used wine version:
> 57a67ebcceb08639736f218f0f545aa41737ad96
>
> graphic card:
> GeF
On Wednesday October 3 2007 11:44, Roderick Colenbrander wrote:
> Hi,
>
> Thanks to Chris his recent child window work, there is now support for
> OpenGL child windows in Wine. For the exact details read bug 2398 or Chris
> his patches. In short the patches use XComposite were poss
737ad96
>
> graphic card:
> GeForce 7800 GTX
>
> driver:
> NVIDIA UNIX x86 Kernel Module 100.14.11
>
> Thanks for the try to fix it anyway.
>
>
> Roderick Colenbrander wrote:
> > Hi,
> >
> > Thanks to Chris his recent child window work, there
x86 Kernel Module 100.14.11
Thanks for the try to fix it anyway.
Roderick Colenbrander wrote:
> Hi,
>
> Thanks to Chris his recent child window work, there is now support for OpenGL
> child windows in Wine. For the exact details read bug 2398 or Chris his
> patches. In short
Hi,
Thanks to Chris his recent child window work, there is now support for OpenGL
child windows in Wine. For the exact details read bug 2398 or Chris his
patches. In short the patches use XComposite were possible and else X pixmaps.
Not all drivers support both properly yet but for compiz
And I just discovered
http://developer.3dlabs.com/downloads/shadergen/index.htm
:):) neat... a working opengl program witch i can not only run but
install on wine :>
thx again,
--
Paweł Różański
Hi,
OpenGL pixelformats
Next to the windowed opengl issues, there's the pixelformat limitation in Wine.
Right now only one pixelformat can be used. Most programs use ChoosePixelFormat
using which you can request a pixelformat but the call isn't guaranteed to give
you back what you want. For
Say, that post is hard to read at the main archive:
http://winehq.org/pipermail/wine-devel/2007-April/055817.html
but it's more readable at another archive,
http://marc.info/?l=wine-devel&m=117624165731188&w=2
ue to
pixelformats. I believe that perhaps a few of them are fixable (by adding more
hacks or by lieing to programs). If we had more pixelformats, I think the
issues could be fixed. OpenGL child windows would fix this issue as the child
doesn't have to use the same pixelformat as its parent
Am Freitag, 6. Oktober 2006 18:09 schrieb Willie Sippel:
> Am Freitag, 6. Oktober 2006 15:26 schrieb Ulrich Czekalla:
> > From our discussions at wineconf we concluded that overriding the
> > various functions such as glViewport and glScissor will get us there for
> > most applications.
> >
> > Th
> Am Freitag, 6. Oktober 2006 15:26 schrieb Ulrich Czekalla:
> > From our discussions at wineconf we concluded that overriding the
> various
> > functions such as glViewport and glScissor will get us there for most
> > applications.
> >
> > The only thing this will not do is handle the case where
Am Freitag, 6. Oktober 2006 15:26 schrieb Ulrich Czekalla:
> From our discussions at wineconf we concluded that overriding the various
> functions such as glViewport and glScissor will get us there for most
> applications.
>
> The only thing this will not do is handle the case where a child window
On Fri, Oct 06, 2006 at 01:30:43PM +0200, Roderick Colenbrander wrote:
> Hi,
>
> The plan is to get all the X-specific opengl code into winex11.drv and to get
> rid of things like ExtEscape. I also want to avoid using WineGLContext in
> opengl32.dll as I plan to change this too. A call like Sync
e WineGLContext
code. There's no need for much win32-specific stuff inside winex11.drv
Roderick
> This patch override glViewport and glScissor to correctly position and
> size
> opengl child windows.
>
> I've only tested this patch with Google Earth and Google Sketchup so I
Ulrich Czekalla wrote:
This patch override glViewport and glScissor to correctly position and size
opengl child windows.
I've only tested this patch with Google Earth and Google Sketchup so I'd
like to get some feedback to see if this solves the problem for your
application.
R
Hello,
Dan Kegel wrote:
he suggests using the new GL_EXT_framebuffer_object OpenGL extension.
I checked around a bit, and it appears to be at least
partly supported by the latest NVidia and ATI drivers.
I'm tempted to say skip the workaround, at least for
the first pass, and just implement the
On Thu, Oct 20, 2005 at 08:25:42PM +0200, Lionel Ulmer wrote:
> Ah I understand now. Do you know when the 'in DIB section' patch will be
> sent to wine-patches (maybe after the 0.9 freeze) ?
Ok, here's a patch for fun.
It has one really nasty hack that needs to be sorted out - that's how
to keep
On 10/20/05, Lionel Ulmer <[EMAIL PROTECTED]> wrote:
> Ah I understand now. Do you know when the 'in DIB section' patch will be
> sent to wine-patches (maybe after the 0.9 freeze) ?
>
> I think once this is in, I will try (for fun) to see if I can get a hacked
> version of wgl.c together which uses
> Yeah, this is for a customer of ours who has the OpenGL in child
> windows problem. The easiest way around this was to get them to
> modify their code to draw onto dibsections and blit to the window.
> Then all we needed to do was to implement the OpenGL on dibsection
> bit.
Ah I understand now
On Wed, Oct 19, 2005 at 11:31:07PM +0200, Lionel Ulmer wrote:
> On Wed, Oct 19, 2005 at 10:24:32PM +0100, Huw D M Davies wrote:
> > It's going to be used to enable OpenGL to draw on dibsections (ie
> > PFD_DRAW_TO_BITMAP). The deal is that while you can use a Window as a
> > glx drawable you can't
On Wed, Oct 19, 2005 at 10:24:32PM +0100, Huw D M Davies wrote:
> It's going to be used to enable OpenGL to draw on dibsections (ie
> PFD_DRAW_TO_BITMAP). The deal is that while you can use a Window as a
> glx drawable you can't use a Pixmap, so the old drawable Escape
> wasn't sufficient. There
On Wed, Oct 19, 2005 at 11:13:03PM +0200, Lionel Ulmer wrote:
> > Which patch is that? I couldn't find it...
>
> * dlls/x11drv/bitmap.c, dlls/x11drv/init.c, dlls/x11drv/opengl.c,
> dlls/x11drv/x11drv.h:
> Huw Davies <[EMAIL PROTECTED]>
> Add an x11drv escape
> Which patch is that? I couldn't find it...
* dlls/x11drv/bitmap.c, dlls/x11drv/init.c, dlls/x11drv/opengl.c,
dlls/x11drv/x11drv.h:
Huw Davies <[EMAIL PROTECTED]>
Add an x11drv escape that returns a glx drawable.
At the tim
Lionel Ulmer wrote:
Huw has done some work on this using pbuffers but I'm not sure how far he's got.
I thought it was GLXPixmaps seeing the patch he submitted to wine-cvs :-)
Which patch is that? I couldn't find it...
--
Trying to get a job as a c++ developer? See
http://kegel.com/acade
> Huw has done some work on this using pbuffers but I'm not sure how far he's
> got.
I thought it was GLXPixmaps seeing the patch he submitted to wine-cvs :-)
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
--- Dan Kegel <[EMAIL PROTECTED]> wrote:
> Lionel Ulmer wrote:
> > On Tue, Oct 18, 2005 at 12:08:04AM -0700, Dan Kegel wrote:
> >
> >>I'm tempted to say skip the workaround, at least for
> >>the first pass, and just implement the real fix using
> >>the opengl extension. As Sippel said, people w
Lionel Ulmer wrote:
On Tue, Oct 18, 2005 at 12:08:04AM -0700, Dan Kegel wrote:
I'm tempted to say skip the workaround, at least for
the first pass, and just implement the real fix using
the opengl extension. As Sippel said, people who
use apps like Lightwave (and maybe Quake3 Radiant :-)
tend
--- Lionel Ulmer <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 18, 2005 at 12:08:04AM -0700, Dan Kegel wrote:
> > I'm tempted to say skip the workaround, at least for
> > the first pass, and just implement the real fix using
> > the opengl extension. As Sippel said, people who
> > use apps like Light
On Tue, Oct 18, 2005 at 12:08:04AM -0700, Dan Kegel wrote:
> I'm tempted to say skip the workaround, at least for
> the first pass, and just implement the real fix using
> the opengl extension. As Sippel said, people who
> use apps like Lightwave (and maybe Quake3 Radiant :-)
> tend to have the la
The change back in January or so to no longer give
each window its own x window seems to have caused
an upheaval in the opengl world. The first app to
report a problem was Lightwave 3D:
http://bugs.winehq.org/show_bug.cgi?id=2398
followed by
http://bugs.winehq.org/show_bug.cgi?id=2908 WeatherSco
41 matches
Mail list logo
