> Anyway, many people think of OpenGL as just 3D, but it is extremely
> competent for 2D (given a good driver).
That's where your argument falls down.
I wouldn't be surprised if even a crappy OpenGL implementation could beat
plain GDI. However I'd guess most OpenGL drivers are optimised for commo
Jamie Lokier wrote:
Dan Sandberg wrote:
When the screen is "painted" the DAC's read from the host video buffer
(1600x1200) and interpret it as RGB. Somewhere they "hit" the left
boundary of the separate viewport that you have set up and bang, on the
fly they switch to reading 800x600-organ
Dan Sandberg wrote:
> When the screen is "painted" the DAC's read from the host video buffer
> (1600x1200) and interpret it as RGB. Somewhere they "hit" the left
> boundary of the separate viewport that you have set up and bang, on the
> fly they switch to reading 800x600-organized data from the
Jamie Lokier wrote:
Dan Sandberg wrote:
Creating a rectangular direct output area in OpenGL is actually like
vitualizing a graphics card.
That is what X's XF86DGA ("Direct Graphics Adapter") feature does.
And I believe SDL already supports XF86DGA when in full screen mode.
It is
Dan Sandberg wrote:
> Creating a rectangular direct output area in OpenGL is actually like
> vitualizing a graphics card.
That is what X's XF86DGA ("Direct Graphics Adapter") feature does.
And I believe SDL already supports XF86DGA when in full screen mode.
> It is updated at native speed
Not n
Fabrice Bellard wrote:
Dan Sandberg wrote:
Just curious...
Are you using an OpenGL directdraw surface for the graphics emulation
in Qemu?
If not, then consider the benefits:
1. It is much faster than any native graphics 2D/3D primitives like
Windows GDI
2: It gives full control over things
Dan Sandberg wrote:
Just curious...
Are you using an OpenGL directdraw surface for the graphics emulation in
Qemu?
If not, then consider the benefits:
1. It is much faster than any native graphics 2D/3D primitives like
Windows GDI
2: It gives full control over things like window or fullscree
Dan Sandberg wrote:
Just curious...
Are you using an OpenGL directdraw surface for the graphics emulation
in Qemu?
If not, then consider the benefits:
1. It is much faster than any native graphics 2D/3D primitives like
Windows GDI
2: It gives full control over things like window or fullscreen
On Thu, May 11, 2006 at 04:57:23PM +0200, Jan Marten Simons wrote:
> Am Donnerstag, 11. Mai 2006 15:04 schrieb Dan Sandberg:
> > Are you using an OpenGL directdraw surface for the graphics emulation in
> > Qemu?
>
> Qemu is using SDL, as this is a very portable library/framework. I'm not
> sure,
Dan Sandberg wrote:
Paul Brook wrote:
On Wednesday 10 May 2006 23:05, Fabrice Bellard wrote:
In order to stop the release of incomplete BGR patches, I am
implementing a more complete patch. I am just adding depth = 32 with BGR
instead of RGB. If other pixel formats are wanted, you should si
Am Donnerstag, 11. Mai 2006 15:04 schrieb Dan Sandberg:
> Are you using an OpenGL directdraw surface for the graphics emulation in
> Qemu?
Qemu is using SDL, as this is a very portable library/framework. I'm not sure,
if SDL uses DirectX on Win32, but I'd rather think it does not. Of course one
Paul Brook wrote:
On Wednesday 10 May 2006 23:05, Fabrice Bellard wrote:
In order to stop the release of incomplete BGR patches, I am
implementing a more complete patch. I am just adding depth = 32 with BGR
instead of RGB. If other pixel formats are wanted, you should signal it
now.
I
On Wednesday 10 May 2006 23:05, Fabrice Bellard wrote:
> In order to stop the release of incomplete BGR patches, I am
> implementing a more complete patch. I am just adding depth = 32 with BGR
> instead of RGB. If other pixel formats are wanted, you should signal it
> now.
I don't have any paticul
Fabrice Bellard <[EMAIL PROTECTED]> wrote:
> In order to stop the release of incomplete BGR patches, I am
> implementing a more complete patch. I am just adding depth = 32 with BGR
> instead of RGB. If other pixel formats are wanted, you should signal it now.
I added an "int bgr;" to the
In order to stop the release of incomplete BGR patches, I am
implementing a more complete patch. I am just adding depth = 32 with BGR
instead of RGB. If other pixel formats are wanted, you should signal it now.
Fabrice.
___
Qemu-devel mailing list
Q
> autodetect what color format to use. Also putting if inside the inner loop
> of the low-level conversion routines is a bad idea.
While that's per-se true, maybe it's not such a big deal. The branch is
going to be perfectly predictable since the condition stays the same
for the entire run, so
This was the original Solaris patch that I based my own patch on. At
Paul Brook's suggestion, I made the translations more static (and as you
are suggesting now, Anthony.) However, Fabrice commented that my patch
was not correct for various reasons (quote from Fabrice on 2006-05-01):
"Hi,
I did
Ben Taylor wrote:
Enclosed is a patch that fixes the color mapping when running qemu on a
Solaris/Sparc
system. To enable the color mapping bgr, call qemu with the flag "-bgr".
This patch *requires* the qemu-0.8.1cvs-sparc-solaris.patch diff that was posted
earlier today.
I separated out this
On Wednesday 10 May 2006 19:16, Ben Taylor wrote:
> Enclosed is a patch that fixes the color mapping when running qemu on a
> Solaris/Sparc system. To enable the color mapping bgr, call qemu with the
> flag "-bgr".
We've been over this several times before. qemu should be able to autodetect
what
Enclosed is a patch that fixes the color mapping when running qemu on a
Solaris/Sparc
system. To enable the color mapping bgr, call qemu with the flag "-bgr".
This patch *requires* the qemu-0.8.1cvs-sparc-solaris.patch diff that was posted
earlier today.
I separated out this patch as there has
20 matches
Mail list logo
