[Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Ben Taylor]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]


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 been much discussion about fixing the bgr
problem, but I haven't seen any other code posted.  This has been tested with
Win98SE and DamnSmallLinux on an Ultra 80 running Solaris 10.

Note:  VNC and Sparc are still not playing nicely, so you will see inverted colors if
you run qemu on a Solaris Sparc host and display with vnc.

Ben

[-- Attachment #2: qemu-0.8.1cvs-solaris-bgr.patch --]
[-- Type: text/x-patch, Size: 3586 bytes --]

diff -ruN qemu-solaris-sparc/hw/vga.c qemu/hw/vga.c
--- qemu-solaris-sparc/hw/vga.c	2006-04-08 21:06:34.000000000 -0400
+++ qemu/hw/vga.c	2006-05-10 12:31:31.059297000 -0400
@@ -790,23 +790,43 @@
 
 static inline unsigned int rgb_to_pixel8(unsigned int r, unsigned int g, unsigned b)
 {
+if (bgr_display_enabled) {
+    return ((b >> 5) << 5) | ((g >> 5) << 2) | (r >> 6);
+}
+else {
     return ((r >> 5) << 5) | ((g >> 5) << 2) | (b >> 6);
 }
+}
 
 static inline unsigned int rgb_to_pixel15(unsigned int r, unsigned int g, unsigned b)
 {
+if (bgr_display_enabled) {
+    return ((b >> 3) << 10) | ((g >> 3) << 5) | (r >> 3);
+}
+else {
     return ((r >> 3) << 10) | ((g >> 3) << 5) | (b >> 3);
 }
+}
 
 static inline unsigned int rgb_to_pixel16(unsigned int r, unsigned int g, unsigned b)
 {
+if (bgr_display_enabled) {
+    return ((b >> 3) << 11) | ((g >> 2) << 5) | (r >> 3);
+}
+else {
     return ((r >> 3) << 11) | ((g >> 2) << 5) | (b >> 3);
 }
+}
 
 static inline unsigned int rgb_to_pixel32(unsigned int r, unsigned int g, unsigned b)
 {
+if (bgr_display_enabled) {
+    return (b << 16) | (g << 8) | r;
+}
+else {
     return (r << 16) | (g << 8) | b;
 }
+}
 
 #define DEPTH 8
 #include "vga_template.h"
@@ -1366,6 +1386,8 @@
 
     if (disp_width != s->last_width ||
         height != s->last_height) {
+        if (cirrus_vga_enabled && s->get_bpp(s) >= 8)
+            memset(s->vram_ptr, 0xff, s->vram_size);
         dpy_resize(s->ds, disp_width, height);
         s->last_scr_width = disp_width;
         s->last_scr_height = height;
diff -ruN qemu-solaris-sparc/vl.c qemu/vl.c
--- qemu-solaris-sparc/vl.c	2006-05-10 12:37:40.467126000 -0400
+++ qemu/vl.c	2006-05-10 12:31:46.354278000 -0400
@@ -130,6 +130,7 @@
 int vm_running;
 int rtc_utc = 1;
 int cirrus_vga_enabled = 1;
+int bgr_display_enabled = 0;
 #ifdef TARGET_SPARC
 int graphic_width = 1024;
 int graphic_height = 768;
@@ -4626,6 +4627,7 @@
            "-m megs         set virtual RAM size to megs MB [default=%d]\n"
            "-smp n          set the number of CPUs to 'n' [default=1]\n"
            "-nographic      disable graphical output and redirect serial I/Os to console\n"
+           "-bgr            invert colors for HOSTS using certain SPARC frame buffers\n"
 #ifndef _WIN32
 	   "-k language     use keyboard layout (for example \"fr\" for French)\n"
 #endif
@@ -4782,6 +4784,7 @@
     QEMU_OPTION_cirrusvga,
     QEMU_OPTION_g,
     QEMU_OPTION_std_vga,
+    QEMU_OPTION_bgr,
     QEMU_OPTION_monitor,
     QEMU_OPTION_serial,
     QEMU_OPTION_parallel,
@@ -4861,6 +4864,7 @@
     { "full-screen", 0, QEMU_OPTION_full_screen },
     { "pidfile", HAS_ARG, QEMU_OPTION_pidfile },
     { "win2k-hack", 0, QEMU_OPTION_win2k_hack },
+    { "bgr", 0, QEMU_OPTION_bgr },
     { "usbdevice", HAS_ARG, QEMU_OPTION_usbdevice },
     { "smp", HAS_ARG, QEMU_OPTION_smp },
     { "vnc", HAS_ARG, QEMU_OPTION_vnc },
@@ -5365,6 +5369,9 @@
             case QEMU_OPTION_std_vga:
                 cirrus_vga_enabled = 0;
                 break;
+            case QEMU_OPTION_bgr:
+                bgr_display_enabled = 1;
+                break;
             case QEMU_OPTION_g:
                 {
                     const char *p;
diff -ruN qemu-solaris-sparc/vl.h qemu/vl.h
--- qemu-solaris-sparc/vl.h	2006-05-03 18:02:44.000000000 -0400
+++ qemu/vl.h	2006-05-10 12:31:51.368923000 -0400
@@ -135,6 +135,7 @@
 extern int bios_size;
 extern int rtc_utc;
 extern int cirrus_vga_enabled;
+extern int bgr_display_enabled;
 extern int graphic_width;
 extern int graphic_height;
 extern int graphic_depth;

Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Anthony Liguori]

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 patch as there has been much discussion about fixing the bgr
> problem, but I haven't seen any other code posted.  This has been tested with
> Win98SE and DamnSmallLinux on an Ultra 80 running Solaris 10.
>
> Note:  VNC and Sparc are still not playing nicely, so you will see inverted colors if
> you run qemu on a Solaris Sparc host and display with vnc.
>   

This is going to almost certainly going to have a negative performance 
consequence.  A better solution would be introduce a second set of 
functions that were byte swapped and set the rgb_to_pixel function 
pointer appropriately if bgr is enabled.

I would expect that you can automate the selecting of bgr too based on 
the host architecture and the target architecture.  There shouldn't be a 
need for a new command line option.

If you added a byte_order member to the DisplayState, this would fix the 
vnc case too.

Regards,

Anthony Liguori

> Ben
> ------------------------------------------------------------------------
>
> diff -ruN qemu-solaris-sparc/hw/vga.c qemu/hw/vga.c
> --- qemu-solaris-sparc/hw/vga.c	2006-04-08 21:06:34.000000000 -0400
> +++ qemu/hw/vga.c	2006-05-10 12:31:31.059297000 -0400
> @@ -790,23 +790,43 @@
>  
>  static inline unsigned int rgb_to_pixel8(unsigned int r, unsigned int g, unsigned b)
>  {
> +if (bgr_display_enabled) {
> +    return ((b >> 5) << 5) | ((g >> 5) << 2) | (r >> 6);
> +}
> +else {
>      return ((r >> 5) << 5) | ((g >> 5) << 2) | (b >> 6);
>  }
> +}
>  
>  static inline unsigned int rgb_to_pixel15(unsigned int r, unsigned int g, unsigned b)
>  {
> +if (bgr_display_enabled) {
> +    return ((b >> 3) << 10) | ((g >> 3) << 5) | (r >> 3);
> +}
> +else {
>      return ((r >> 3) << 10) | ((g >> 3) << 5) | (b >> 3);
>  }
> +}
>  
>  static inline unsigned int rgb_to_pixel16(unsigned int r, unsigned int g, unsigned b)
>  {
> +if (bgr_display_enabled) {
> +    return ((b >> 3) << 11) | ((g >> 2) << 5) | (r >> 3);
> +}
> +else {
>      return ((r >> 3) << 11) | ((g >> 2) << 5) | (b >> 3);
>  }
> +}
>  
>  static inline unsigned int rgb_to_pixel32(unsigned int r, unsigned int g, unsigned b)
>  {
> +if (bgr_display_enabled) {
> +    return (b << 16) | (g << 8) | r;
> +}
> +else {
>      return (r << 16) | (g << 8) | b;
>  }
> +}
>  
>  #define DEPTH 8
>  #include "vga_template.h"
> @@ -1366,6 +1386,8 @@
>  
>      if (disp_width != s->last_width ||
>          height != s->last_height) {
> +        if (cirrus_vga_enabled && s->get_bpp(s) >= 8)
> +            memset(s->vram_ptr, 0xff, s->vram_size);
>          dpy_resize(s->ds, disp_width, height);
>          s->last_scr_width = disp_width;
>          s->last_scr_height = height;
> diff -ruN qemu-solaris-sparc/vl.c qemu/vl.c
> --- qemu-solaris-sparc/vl.c	2006-05-10 12:37:40.467126000 -0400
> +++ qemu/vl.c	2006-05-10 12:31:46.354278000 -0400
> @@ -130,6 +130,7 @@
>  int vm_running;
>  int rtc_utc = 1;
>  int cirrus_vga_enabled = 1;
> +int bgr_display_enabled = 0;
>  #ifdef TARGET_SPARC
>  int graphic_width = 1024;
>  int graphic_height = 768;
> @@ -4626,6 +4627,7 @@
>             "-m megs         set virtual RAM size to megs MB [default=%d]\n"
>             "-smp n          set the number of CPUs to 'n' [default=1]\n"
>             "-nographic      disable graphical output and redirect serial I/Os to console\n"
> +           "-bgr            invert colors for HOSTS using certain SPARC frame buffers\n"
>  #ifndef _WIN32
>  	   "-k language     use keyboard layout (for example \"fr\" for French)\n"
>  #endif
> @@ -4782,6 +4784,7 @@
>      QEMU_OPTION_cirrusvga,
>      QEMU_OPTION_g,
>      QEMU_OPTION_std_vga,
> +    QEMU_OPTION_bgr,
>      QEMU_OPTION_monitor,
>      QEMU_OPTION_serial,
>      QEMU_OPTION_parallel,
> @@ -4861,6 +4864,7 @@
>      { "full-screen", 0, QEMU_OPTION_full_screen },
>      { "pidfile", HAS_ARG, QEMU_OPTION_pidfile },
>      { "win2k-hack", 0, QEMU_OPTION_win2k_hack },
> +    { "bgr", 0, QEMU_OPTION_bgr },
>      { "usbdevice", HAS_ARG, QEMU_OPTION_usbdevice },
>      { "smp", HAS_ARG, QEMU_OPTION_smp },
>      { "vnc", HAS_ARG, QEMU_OPTION_vnc },
> @@ -5365,6 +5369,9 @@
>              case QEMU_OPTION_std_vga:
>                  cirrus_vga_enabled = 0;
>                  break;
> +            case QEMU_OPTION_bgr:
> +                bgr_display_enabled = 1;
> +                break;
>              case QEMU_OPTION_g:
>                  {
>                      const char *p;
> diff -ruN qemu-solaris-sparc/vl.h qemu/vl.h
> --- qemu-solaris-sparc/vl.h	2006-05-03 18:02:44.000000000 -0400
> +++ qemu/vl.h	2006-05-10 12:31:51.368923000 -0400
> @@ -135,6 +135,7 @@
>  extern int bios_size;
>  extern int rtc_utc;
>  extern int cirrus_vga_enabled;
> +extern int bgr_display_enabled;
>  extern int graphic_width;
>  extern int graphic_height;
>  extern int graphic_depth;
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>   

Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Leonardo E. Reiter]

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 not accept your patch for two reasons:

1) You changed the guest vga frame buffer format and I don't think this
is what you wanted (it can be useful to emulate VGA on big endian guests
though - the current implementation for ppc guests is a hack). What is
needed is to swap the host pixel format.

2) You added support for RGB swapping for 8/15/16 depths and I am not
sure this is useful. Endianness swapping would be more useful for 15/16
depths.

Fabrice."

I don't know how to get around #1, and certainly not without some
serious performance penalty.  I only implemented the #2 bit because it
was part of the original patch that I based mine on.  I agree that it's
not nearly as relevant as 24-bit.  In any case:

http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00195.html

http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00230.html

Just FYI in case it helps anyone.  There is no performance degradation
at all with that version of the patch, and it's helping some of my
SunRay customers with the colors in 24-bit mode just fine when running
Windows XP guests off a Linux server.  It does not address the VNC bits
however, as it was developed before the built-in VNC was available.

Regards,

Leo Reiter

Anthony Liguori wrote:
> 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 patch as there has been much discussion about
>> fixing the bgr
>> problem, but I haven't seen any other code posted.  This has been
>> tested with
>> Win98SE and DamnSmallLinux on an Ultra 80 running Solaris 10.
>>
>> Note:  VNC and Sparc are still not playing nicely, so you will see
>> inverted colors if
>> you run qemu on a Solaris Sparc host and display with vnc.
>>   
> 
> 
> This is going to almost certainly going to have a negative performance
> consequence.  A better solution would be introduce a second set of
> functions that were byte swapped and set the rgb_to_pixel function
> pointer appropriately if bgr is enabled.
> 
> I would expect that you can automate the selecting of bgr too based on
> the host architecture and the target architecture.  There shouldn't be a
> need for a new command line option.
> 
> If you added a byte_order member to the DisplayState, this would fix the
> vnc case too.
> 
> Regards,
> 
> Anthony Liguori
> 
>> Ben
>> ------------------------------------------------------------------------
>>
>> diff -ruN qemu-solaris-sparc/hw/vga.c qemu/hw/vga.c
>> --- qemu-solaris-sparc/hw/vga.c    2006-04-08 21:06:34.000000000 -0400
>> +++ qemu/hw/vga.c    2006-05-10 12:31:31.059297000 -0400
>> @@ -790,23 +790,43 @@
>>  
>>  static inline unsigned int rgb_to_pixel8(unsigned int r, unsigned int
>> g, unsigned b)
>>  {
>> +if (bgr_display_enabled) {
>> +    return ((b >> 5) << 5) | ((g >> 5) << 2) | (r >> 6);
>> +}
>> +else {
>>      return ((r >> 5) << 5) | ((g >> 5) << 2) | (b >> 6);
>>  }
>> +}
>>  
>>  static inline unsigned int rgb_to_pixel15(unsigned int r, unsigned
>> int g, unsigned b)
>>  {
>> +if (bgr_display_enabled) {
>> +    return ((b >> 3) << 10) | ((g >> 3) << 5) | (r >> 3);
>> +}
>> +else {
>>      return ((r >> 3) << 10) | ((g >> 3) << 5) | (b >> 3);
>>  }
>> +}
>>  
>>  static inline unsigned int rgb_to_pixel16(unsigned int r, unsigned
>> int g, unsigned b)
>>  {
>> +if (bgr_display_enabled) {
>> +    return ((b >> 3) << 11) | ((g >> 2) << 5) | (r >> 3);
>> +}
>> +else {
>>      return ((r >> 3) << 11) | ((g >> 2) << 5) | (b >> 3);
>>  }
>> +}
>>  
>>  static inline unsigned int rgb_to_pixel32(unsigned int r, unsigned
>> int g, unsigned b)
>>  {
>> +if (bgr_display_enabled) {
>> +    return (b << 16) | (g << 8) | r;
>> +}
>> +else {
>>      return (r << 16) | (g << 8) | b;
>>  }
>> +}
>>  
>>  #define DEPTH 8
>>  #include "vga_template.h"
>> @@ -1366,6 +1386,8 @@
>>  
>>      if (disp_width != s->last_width ||
>>          height != s->last_height) {
>> +        if (cirrus_vga_enabled && s->get_bpp(s) >= 8)
>> +            memset(s->vram_ptr, 0xff, s->vram_size);
>>          dpy_resize(s->ds, disp_width, height);
>>          s->last_scr_width = disp_width;
>>          s->last_scr_height = height;
>> diff -ruN qemu-solaris-sparc/vl.c qemu/vl.c
>> --- qemu-solaris-sparc/vl.c    2006-05-10 12:37:40.467126000 -0400
>> +++ qemu/vl.c    2006-05-10 12:31:46.354278000 -0400
>> @@ -130,6 +130,7 @@
>>  int vm_running;
>>  int rtc_utc = 1;
>>  int cirrus_vga_enabled = 1;
>> +int bgr_display_enabled = 0;
>>  #ifdef TARGET_SPARC
>>  int graphic_width = 1024;
>>  int graphic_height = 768;
>> @@ -4626,6 +4627,7 @@
>>             "-m megs         set virtual RAM size to megs MB
>> [default=%d]\n"
>>             "-smp n          set the number of CPUs to 'n' [default=1]\n"
>>             "-nographic      disable graphical output and redirect
>> serial I/Os to console\n"
>> +           "-bgr            invert colors for HOSTS using certain
>> SPARC frame buffers\n"
>>  #ifndef _WIN32
>>         "-k language     use keyboard layout (for example \"fr\" for
>> French)\n"
>>  #endif
>> @@ -4782,6 +4784,7 @@
>>      QEMU_OPTION_cirrusvga,
>>      QEMU_OPTION_g,
>>      QEMU_OPTION_std_vga,
>> +    QEMU_OPTION_bgr,
>>      QEMU_OPTION_monitor,
>>      QEMU_OPTION_serial,
>>      QEMU_OPTION_parallel,
>> @@ -4861,6 +4864,7 @@
>>      { "full-screen", 0, QEMU_OPTION_full_screen },
>>      { "pidfile", HAS_ARG, QEMU_OPTION_pidfile },
>>      { "win2k-hack", 0, QEMU_OPTION_win2k_hack },
>> +    { "bgr", 0, QEMU_OPTION_bgr },
>>      { "usbdevice", HAS_ARG, QEMU_OPTION_usbdevice },
>>      { "smp", HAS_ARG, QEMU_OPTION_smp },
>>      { "vnc", HAS_ARG, QEMU_OPTION_vnc },
>> @@ -5365,6 +5369,9 @@
>>              case QEMU_OPTION_std_vga:
>>                  cirrus_vga_enabled = 0;
>>                  break;
>> +            case QEMU_OPTION_bgr:
>> +                bgr_display_enabled = 1;
>> +                break;
>>              case QEMU_OPTION_g:
>>                  {
>>                      const char *p;
>> diff -ruN qemu-solaris-sparc/vl.h qemu/vl.h
>> --- qemu-solaris-sparc/vl.h    2006-05-03 18:02:44.000000000 -0400
>> +++ qemu/vl.h    2006-05-10 12:31:51.368923000 -0400
>> @@ -135,6 +135,7 @@
>>  extern int bios_size;
>>  extern int rtc_utc;
>>  extern int cirrus_vga_enabled;
>> +extern int bgr_display_enabled;
>>  extern int graphic_width;
>>  extern int graphic_height;
>>  extern int graphic_depth;
>>  
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Qemu-devel mailing list
>> Qemu-devel@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>   
> 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

-- 
Leonardo E. Reiter
Vice President of Product Development, CTO

Win4Lin, Inc.
Virtual Computing that means Business
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com

Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Paul Brook]

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 color format to use. Also putting if inside the inner loop of the 
low-level conversion routines is a bad idea.

Paul

Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Julian Seward]

> 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 I'd be surprised if you even lost one host cycle
per iteration overall.  Basically the hardware will fold it out.

J

Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Fabrice Bellard]

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.

Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Paul Brook]

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 paticular favourite pixel formats, but qemu now has [at 
least] 3 different sets of low-level pixel conversion routines (vga, tcx and 
pl110). If you're feeling really enthusiastic it would be nice if they could 
be unified :-) 
It's one of the things I've been meaning to look at when I've nothing better 
to do, but haven't got round to yet..

Paul

Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Dan Sandberg]

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 don't have any paticular favourite pixel formats, but qemu now has [at 
>least] 3 different sets of low-level pixel conversion routines (vga, tcx and 
>pl110). If you're feeling really enthusiastic it would be nice if they could 
>be unified :-) 
>It's one of the things I've been meaning to look at when I've nothing better 
>to do, but haven't got round to yet..
>
>Paul
>
>
>
>_______________________________________________
>Qemu-devel mailing list
>Qemu-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>  
>
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 mode in 
any (almost) resolution and color depth.
3. It is operating system independent.
4. It handles things like RGB, BGR, 24bit, 15bit, 16bit, 8bit, alpha 
channel etc in hardware, all you have to do is select the pixelformat 
you like to use for the buffer and OpenGL does the rest - lightning 
fast, minimum CPU-load.

My suggestion would be to write a frontend similar to VMware's for Qemu 
in Lazarus. Why Lazarus?
1. The fantastic GLscene is available for Lazarus making 
OpenGL-programming easy. Try: http://www.skinhat.com/3dpack/
2. With Lazarus a RAD graphic frontend based on OpenGL can be made and 
directly compileable for most operating systems without need for 
modifications.

Hope someone likes the idea, otherwise I will have to do it myself if I 
can find some spare time.

Dan

Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Jan Marten Simons]

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 
might want to check this and maybe have a look at the SDL mail lists, if 
DirectX was discussed there.

> My suggestion would be to write a frontend similar to VMware's for Qemu
> in Lazarus. Why Lazarus?
> 1. The fantastic GLscene is available for Lazarus making
> OpenGL-programming easy. Try: http://www.skinhat.com/3dpack/
> 2. With Lazarus a RAD graphic frontend based on OpenGL can be made and
> directly compileable for most operating systems without need for
> modifications.

There already are a few projects for external qemu GUIs, but for an internal 
GUI it would have to be done in SDL, too, as to not introduce further 
dependencies. Please keep in mind that qemu is ported to many platforms and 
therefor the code would have to be very portable anyways.
If you're keen on doing a GUI in Lazarus, feel free to do so, but have a look 
at the ml archive and some existing GUIs first.

With regards,
Jan Simons

Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Jim C. Brown]

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, 
> if SDL uses DirectX on Win32, but I'd rather think it does not. Of course one 
> might want to check this and maybe have a look at the SDL mail lists, if 
> DirectX was discussed there.

He is askinng about OpenGL, not DirectX.

Dunno if it is the default, but iirc SDL supports OpenGL on Windows.

> 
> > My suggestion would be to write a frontend similar to VMware's for Qemu
> > in Lazarus. Why Lazarus?
> > 1. The fantastic GLscene is available for Lazarus making
> > OpenGL-programming easy. Try: http://www.skinhat.com/3dpack/
> > 2. With Lazarus a RAD graphic frontend based on OpenGL can be made and
> > directly compileable for most operating systems without need for
> > modifications.

SDL has support for OpenGL builtin, so qemu should be able to use that
with only a few modifications.

> 
> There already are a few projects for external qemu GUIs, but for an internal 
> GUI it would have to be done in SDL, too, as to not introduce further 
> dependencies.

No one has tried to make an SDL Gui for qemu. SDL guis tend to be ugly in
general.

There is a well supported GUI for OS X called Q, and there are 2 versions of
qemu that use a GTK GUI internally.

> Please keep in mind that qemu is ported to many platforms and 
> therefor the code would have to be very portable anyways.

Supporting something that runs (or can run) on top of X would catch most of
the platforms that qemu runs on, the only ones I can think of that would need
their own stuff would be Windows and OS X (well OS X has an X server but users
prefer a native GUI there).

> If you're keen on doing a GUI in Lazarus, feel free to do so, but have a look 
> at the ml archive and some existing GUIs first.
> 
> With regards,
> Jan Simons
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Oliver Gerlich]

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 signal it
>>> now.
>>>   
>>
>>
>> I don't have any paticular favourite pixel formats, but qemu now has 
>> [at least] 3 different sets of low-level pixel conversion routines 
>> (vga, tcx and pl110). If you're feeling really enthusiastic it would 
>> be nice if they could be unified :-) It's one of the things I've been 
>> meaning to look at when I've nothing better to do, but haven't got 
>> round to yet..
>>
>> Paul
>>
>>
>>
>> _______________________________________________
>> Qemu-devel mailing list
>> Qemu-devel@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>
>>  
>>

Hi,
some comments on your suggestions:

> 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

Not sure how much faster it is on Windows; currently Qemu uses plain SDL 
for drawing which probably uses DirectDraw under Windows. However, AFAIK 
under Linux SDL is not hardware accelerated in most cases, while OpenGL 
could give hardware acceleration.

> 2: It gives full control over things like window or fullscreen mode in 
> any (almost) resolution and color depth.

AFAIK the windowing/fullscreen stuff is not done by OpenGL itself, but 
by some external library; SDL offers this functionality, GLUT is another 
possibility, and apparently the GlScene lib you mentioned does this as well.

> 3. It is operating system independent.
> 4. It handles things like RGB, BGR, 24bit, 15bit, 16bit, 8bit, alpha 
> channel etc in hardware, all you have to do is select the pixelformat 
> you like to use for the buffer and OpenGL does the rest - lightning 
> fast, minimum CPU-load.

Basically, that sounds like a good idea to me.

> 
> My suggestion would be to write a frontend similar to VMware's for Qemu 
> in Lazarus. Why Lazarus?
> 1. The fantastic GLscene is available for Lazarus making 
> OpenGL-programming easy. Try: http://www.skinhat.com/3dpack/
> 2. With Lazarus a RAD graphic frontend based on OpenGL can be made and 
> directly compileable for most operating systems without need for 
> modifications.
> 
> Hope someone likes the idea, otherwise I will have to do it myself if I 
> can find some spare time.
> 
> Dan

Before you start working on this, I have some suggestions as well:

Is the drawing part really a performance bottleneck? And will this 
really be improved by changing the drawing functions, or wouldn't a 
better graphics card emulation give much more improvements? What does a 
profiler say about this?
I seem to recall that in most cases, SDL doesn't slow down performance 
in Qemu. It might be interesting to see how much the new RGB<->BGR 
conversions costs, though.

Another thing that I think is important is that not all computers have 
OpenGL acceleration. And at least on Linux, software OpenGL rendering is 
quite slow, so a port to OpenGL would probably be a huge drawback for 
some people. If OpenGL is really worth the trouble, one could add OpenGL 
rendering so that people can still use the "old" way of drawing if no 
hardware acceleration is available.

A GUI frontend would be quite nice, I think. So far several people have 
submitted (quite useful) patches for this, but nothing more has happened 
in that direction. Not sure what is required for a GUI that will be 
integrated into Qemu finally...


Thanks,
Oliver

Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Anthony Liguori]

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 mode in 
> any (almost) resolution and color depth.
> 3. It is operating system independent.
> 4. It handles things like RGB, BGR, 24bit, 15bit, 16bit, 8bit, alpha 
> channel etc in hardware, all you have to do is select the pixelformat 
> you like to use for the buffer and OpenGL does the rest - lightning 
> fast, minimum CPU-load.

My own feeling is that a smarter thing to do is to pass the VGA ops to 
another program to actually do the rendering.  I think a GUI that used 
VNC to interact with QEmu would be a very good start.  localhost VNC 
performance seems good enough to me that this should be a reasonable 
approach.

Hardware scaling would, perhaps, be a useful feature of using OpenGL.  
Unfortunately, OpenGL is not available enough widely to make this 
practical in my mind.  I'd rather devote the same effort to fast 
software scaling (via SIMD instructions).

Regards,

Anthony Liguori

> My suggestion would be to write a frontend similar to VMware's for 
> Qemu in Lazarus. Why Lazarus?
> 1. The fantastic GLscene is available for Lazarus making 
> OpenGL-programming easy. Try: http://www.skinhat.com/3dpack/
> 2. With Lazarus a RAD graphic frontend based on OpenGL can be made and 
> directly compileable for most operating systems without need for 
> modifications.
>
> Hope someone likes the idea, otherwise I will have to do it myself if 
> I can find some spare time.
>
> Dan
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Fabrice Bellard]

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 mode in 
> any (almost) resolution and color depth.
> 3. It is operating system independent.
> 4. It handles things like RGB, BGR, 24bit, 15bit, 16bit, 8bit, alpha 
> channel etc in hardware, all you have to do is select the pixelformat 
> you like to use for the buffer and OpenGL does the rest - lightning 
> fast, minimum CPU-load.
> [...]

I am not sure the bottleneck is in the rendering itself and the single 
primitive that QEMU uses (display a rectangle of bitmap) is accelerated 
by every graphic card since many years. But you are free to modify the 
SDL library to include OpenGL rendering if it is not already done :-)

Fabrice.

Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Dan Sandberg]

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 like window or fullscreen mode 
>> in any (almost) resolution and color depth.
>> 3. It is operating system independent.
>> 4. It handles things like RGB, BGR, 24bit, 15bit, 16bit, 8bit, alpha 
>> channel etc in hardware, all you have to do is select the pixelformat 
>> you like to use for the buffer and OpenGL does the rest - lightning 
>> fast, minimum CPU-load.
>> [...]
>
>
> I am not sure the bottleneck is in the rendering itself and the single 
> primitive that QEMU uses (display a rectangle of bitmap) is 
> accelerated by every graphic card since many years. But you are free 
> to modify the SDL library to include OpenGL rendering if it is not 
> already done :-)
>
> Fabrice.
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
OK,
I am no expert at Qemu's inner workings as you are, but I think I have 
seen mentioned that host and guest pixel formats should be kept 
identical for best performance eg. an undesired need to select 16-bit 
graphics on the host when one wants to use high resolution on the guest 
at which resolution the emulated graphics board only supports 16-bit. I 
also get the impression that the quest display area is updated less 
frequently than the native intervall probably to keep CPU-load down and 
also meaning that the guest OS waste CPU-time on rendering that is 
sometimes "thrown away" when it happens in between actual Qemu display 
updates.

To me this suggests that the needed RectangleBlit operation is not 
CPU-transparent and it seems from the discussions that the lower than 
native update frequency may introduce totally new problems like graphic 
artefacts or possibly the guest OS going out of sync with the emulated 
display adapter and a pointer that cannot keep up with fast movements 
sometimes.

Creating a rectangular direct output area in OpenGL is actually like 
vitualizing a graphics card.
It is updated at native speed and you can select pixelformat for that 
area independent of the host pixel format and you do not have to be 
doing any RectangleBlit operation or causing any CPU-load - to my 
understanding at least.

The next logical step would be to emulate a more competent graphics 
board in this rectangular area including hardware acceleration for guest 
RectangleBlit operations etc. This would give much better 2D-performance 
for any guest OS that knows have to take advantage of it and of course 
OpenGL would be used for this too. It is more or less a mapping of 
OpenGL functionality between guest and host OS'es.

No fancy 3D OpenGL stuff is needed, only the very basic 2D functionality 
is required to boast performance in windowed enviroments so even old and 
cheap graphics cards would do the job. It is OS-independent as long you 
can find an OpenGL-driver.
I realize that the latter may be a problem in some cases so I am not 
saying that any of todays possibilities in Qemu should be retired, 
rather that it could be sort of a new plug-in module for those who want 
a virtual display adapter with close to native graphic performance and 
happen to have what is needed in terms of graphic card and drivers.

I am also not suggesting that you should do the hard work Fabrice. I am 
truly impressed of what you are doing and don't understand how you find 
the time.
I am also not suggesting that I know exactly how to do it, I am a 
beginner when it comes to OpenGL-programming and only starting to 
realize the possibilities of it.
So I only wanted to start the discussion and hopeing for an 
OpenGL-genious out there with lots of spare time. :)

Regards
Dan

Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Jamie Lokier]

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 necessarily.  When I tried using mplayer (a video player) with the
video output set to use OpenGL, it was the slowest of all options -
even slower than writing the images though X11 shared memory with a
copy-to-screen bitblt for each frame.

But then, OpenGL drivers vary considerably in their performance and quality.

> and you can select pixelformat for that 
> area independent of the host pixel format and you do not have to be 
> doing any RectangleBlit operation or causing any CPU-load - to my 
> understanding at least.

Well, OpenGL does a RectangleBlit each time it redraws the 3d
rendering area, doesn't it?  If you have hardware accelerated OpenGL
support, that shouldn't use much CPU.  But then, the same is true for
old-fashioned hardware accelerated 2d bitblt, if the pixel format is
supported.

> [...] I am not saying that any of todays possibilities in Qemu
> should be retired, rather that it could be sort of a new plug-in
> module for those who want a virtual display adapter with close to
> native graphic performance and happen to have what is needed in
> terms of graphic card and drivers.

I agree it's worth a look, because it may be faster for some people,
and because it provides access to image scaling (potentially hardware
assisted), which classic X11 bitblt does not.

It might be worth looking at mplayer's OpenGL driver, which does
something similar to what Qemu would need.

Other X features which can do similar things and may provide equal or
better performance are: Xv (used to display video, but generally
provides a resizable overlay; may or may not provide a usable pixel
format), and Xrender.

-- Jamie

Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Dan Sandberg]

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 updated at native speed
>>    
>>
>
>Not necessarily.  When I tried using mplayer (a video player) with the
>video output set to use OpenGL, it was the slowest of all options -
>even slower than writing the images though X11 shared memory with a
>copy-to-screen bitblt for each frame.
>
>But then, OpenGL drivers vary considerably in their performance and quality.
>
>  
>
>>and you can select pixelformat for that 
>>area independent of the host pixel format and you do not have to be 
>>doing any RectangleBlit operation or causing any CPU-load - to my 
>>understanding at least.
>>    
>>
>
>Well, OpenGL does a RectangleBlit each time it redraws the 3d
>rendering area, doesn't it?  If you have hardware accelerated OpenGL
>support, that shouldn't use much CPU.  But then, the same is true for
>old-fashioned hardware accelerated 2d bitblt, if the pixel format is
>supported.
>
>  
>
>>[...] I am not saying that any of todays possibilities in Qemu
>>should be retired, rather that it could be sort of a new plug-in
>>module for those who want a virtual display adapter with close to
>>native graphic performance and happen to have what is needed in
>>terms of graphic card and drivers.
>>    
>>
>
>I agree it's worth a look, because it may be faster for some people,
>and because it provides access to image scaling (potentially hardware
>assisted), which classic X11 bitblt does not.
>
>It might be worth looking at mplayer's OpenGL driver, which does
>something similar to what Qemu would need.
>
>Other X features which can do similar things and may provide equal or
>better performance are: Xv (used to display video, but generally
>provides a resizable overlay; may or may not provide a usable pixel
>format), and Xrender.
>
>-- Jamie
>
>
>_______________________________________________
>Qemu-devel mailing list
>Qemu-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>  
>
Yes, in the worst case the OpenGL-driver is all software emulation and 
then it is slow and CPU-consuming.

It may also be that some old OpenGL-drivers have to emulate a direct 
output area by bitblt operations from an off-screen buffer to the 
on-screen buffer and then there will be no gain, I agree.
But technically that's not the only way to do the trick and newer boards 
should be capable of doing it much smarter without any bitblt operations 
involved.

I still remember my old favorite, the Amiga computer with its unique 
virtual screens that allowed multiple programs to coexist in the same 
physical screen, each with its own display buffer, pixel format and all 
rendering in full speed. That was never done by bitblt-operations, 
instead much smarter by synchronized on-the-fly switching between 
multiple display buffers as the electron beam painted the screen.

Lets say that you want to set up a 800x600 direct output rectangle with 
BGR-pixel format inside a 1600x1200 RGB host screen on a modern card 
with an adequate OpenGL driver.

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 other video 
buffer and interpreting it as BGR. Later on the same video line they 
"hit" the right boundary of the separate viewport and bang they switch 
back to reading from the main buffer and interpreting it as RGB.

As a result the 1600x1200 RGB buffer and the 800x600 BGR buffer are 
equally active and equally often updated on the same physical screen - 
without need for any moving data around, and without any time consuming 
activity at all taking place as all switches are done on the fly in the 
background by special hardware (if the board supports this).

It is like having two separate physical video boards, each with its own 
display buffer.

Regards
Dan

Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Jamie Lokier]

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 other video 
> buffer and interpreting it as BGR. Later on the same video line they 
> "hit" the right boundary of the separate viewport and bang they switch 
> back to reading from the main buffer and interpreting it as RGB.
> 
> As a result the 1600x1200 RGB buffer and the 800x600 BGR buffer are 
> equally active and equally often updated on the same physical screen - 
> without need for any moving data around, and without any time consuming 
> activity at all taking place as all switches are done on the fly in the 
> background by special hardware (if the board supports this).
> 
> It is like having two separate physical video boards, each with its own 
> display buffer.

Thanks; I didn't know OpenGL had that function as well as 3d rendering.

That's what the Xv extension does ("X video") - it's to provide an
overlay to be used by video players.  Xv scales the source image and
mixes it with the primary framebuffer in the way you describe.
However, Xv is intended for non-RGB colourspace source formats, so may
not be suitable for Qemu.  I don't know if Xv sometimes can support RGB.

Since Xv is supported by many video cards, even old ones without 3d,
or without working 3d drivers, I'm surprised that particular OpenGL
function isn't commonly implemented with equal performance.

-- Jamie

Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Dan Sandberg]

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-organized data from the other video 
>>buffer and interpreting it as BGR. Later on the same video line they 
>>"hit" the right boundary of the separate viewport and bang they switch 
>>back to reading from the main buffer and interpreting it as RGB.
>>
>>As a result the 1600x1200 RGB buffer and the 800x600 BGR buffer are 
>>equally active and equally often updated on the same physical screen - 
>>without need for any moving data around, and without any time consuming 
>>activity at all taking place as all switches are done on the fly in the 
>>background by special hardware (if the board supports this).
>>
>>It is like having two separate physical video boards, each with its own 
>>display buffer.
>>    
>>
>
>Thanks; I didn't know OpenGL had that function as well as 3d rendering.
>
>That's what the Xv extension does ("X video") - it's to provide an
>overlay to be used by video players.  Xv scales the source image and
>mixes it with the primary framebuffer in the way you describe.
>However, Xv is intended for non-RGB colourspace source formats, so may
>not be suitable for Qemu.  I don't know if Xv sometimes can support RGB.
>
>Since Xv is supported by many video cards, even old ones without 3d,
>or without working 3d drivers, I'm surprised that particular OpenGL
>function isn't commonly implemented with equal performance.
>
>-- Jamie
>
>
>_______________________________________________
>Qemu-devel mailing list
>Qemu-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>  
>
Oooops,
I just took a look at a list of OpenGL pixelformats. I really thought I 
had seen BGR there, but I was wrong. Again I am new to OpenGL so do not 
take anything I say for the truth. Here is the list:

GL_ALPHA, GL_ALPHA4,  GL_ALPHA8, GL_ALPHA12, GL_ALPHA16,  GL_LUMINANCE, 
GL_LUMINANCE4, GL_LUMINANCE8,  GL_LUMINANCE12, GL_LUMINANCE16,
GL_LUMINANCE_ALPHA, GL_LUMINANCE4_ALPHA4, GL_LUMINANCE6_ALPHA2, 
GL_LUMINANCE8_ALPHA8, GL_LUMINANCE12_ALPHA4, GL_LUMINANCE12_ALPHA12,
GL_LUMINANCE16_ALPHA16, GL_INTENSITY, GL_INTENSITY4, GL_INTENSITY8,
GL_INTENSITY12, GL_INTENSITY16, GL_R3_G3_B2, GL_RGB, GL_RGB4, GL_RGB5,
GL_RGB8, GL_RGB10, GL_RGB12, GL_RGB16, GL_RGBA, GL_RGBA2,
GL_RGBA4, GL_RGB5_A1, GL_RGBA8, GL_RGB10_A2, GL_RGBA12, or GL_RGBA16

Anyway, many people think of OpenGL as just 3D, but it is extremely 
competent for 2D (given a good driver).
If you want an example of OpenGL superior 2D performance compared to 
Windows GDI routines, then go to
http://www.skinhat.com/lazarus/
and download Lazarus from there with GLscene preinstalled.
(You probably also need to download and install FreePascal from: 
http://www.lazarus.freepascal.org/)
(If you do not have OpenGL drivers installed you have to get them from 
your graphic card manufacturer's homepage.)

There are a large number of OpenGL examples included complete with 
source code ready to compile and test.
Open the example project glscene/demos/bench/canvas/canvas.lpr and 
compile and run by hitting the green arrow.

Windows GDI performance look really bad in comparison. On my computer 
the 20.000 ellipses test with a line width of 2 took 2268 ms for 
standard Windows GDI and 145 ms for the OpenGL 2D-canvas (and its just a 
standard business computer with no fancy graphic card at all).

There are many other nice examples included as well, so it is well worth 
the download.

Regards
Dan

Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Paul Brook]

> 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 common 3D 
operations. OpenGL provides a very wide range of functionality, however if 
you go outside the commonly used (and hence optimized) feature set 
performance is likely to be fairly poor when compared if optimized routines.

> standard Windows GDI and 145 ms for the OpenGL 2D-canvas (and its just a
> standard business computer with no fancy graphic card at all).

If GDI was writing directly to video memory and OpenGL was writing to a buffer 
in system memory that would explain the large difference.


I'm not saying OpenGL is necessarily a bad thing, but it's certainly not (yet) 
what I'd consider good solution. Especially considering that 90% of modern 
graphics cards don't have any open source OpenGL capable drivers.

Paul

Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Ben Taylor]

---- Fabrice Bellard <fabrice@bellard.org> 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 displaystruct in vl.h, but that is now causing a core dump
upon starting qemu with the rest of your patch.

here's the back trace:

#0  0x00033204 in console_show_cursor (s=0x11f95bd8, show=301554760) at vl.h:692
#1  0x0003373c in console_puts (chr=0x36, buf=0x140c18 "QEMU 0.8.1 monitor - type 'help' for more information\n", len=54)
    at /export/src/qemu/May10-V2/qemu-solaris/console.c:825
#2  0x00024eb8 in qemu_chr_write (s=0x36, buf=0x140c18 "QEMU 0.8.1 monitor - type 'help' for more information\n", len=54)
    at /export/src/qemu/May10-V2/qemu-solaris/vl.c:1096
#3  0x0002d208 in term_flush () at /export/src/qemu/May10-V2/qemu-solaris/monitor.c:72
#4  0x0002d27c in term_puts (str=0xffbfb78e "") at /export/src/qemu/May10-V2/qemu-solaris/monitor.c:88
#5  0x0002d2d0 in term_vprintf (fmt=0xfcd68 "QEMU %s monitor - type 'help' for more information\n", ap=0xffbfc820)
    at /export/src/qemu/May10-V2/qemu-solaris/monitor.c:96
#6  0x0002d304 in term_printf (fmt=0xfcd68 "QEMU %s monitor - type 'help' for more information\n")
    at /export/src/qemu/May10-V2/qemu-solaris/monitor.c:103
#7  0x00030470 in monitor_init (hd=0x11f82f38, show_banner=1) at /export/src/qemu/May10-V2/qemu-solaris/monitor.c:2288
#8  0x00029804 in main (argc=7, argv=0xffbff33c) at /export/src/qemu/May10-V2/qemu-solaris/vl.c:5658


Ideas?

Ben