Re: [AD] xwin color-conversion (testers wanted)

[Eric Botcazou <ebotcazou@xxxxxxxxxx>]

> at least for me, BGR is the case. attached is a patch which implements
> assembler color conversion in a blindfolded way. i'd like as much people
> as possible to test it and report back. use my private email so we avoid
> cluttering up the mailinglist with unneccessary emails.

+   /* set up source and destination rectangles */
+   src_rect.height = 1;
+   src_rect.width = sw;
+   src_rect.pitch = BYTES_PER_PIXEL(_xwin.screen_depth);
+
+   dest_rect.height = 1;
+   dest_rect.width = sw;
+   dest_rect.pitch = BYTES_PER_PIXEL(_xwin.fast_visual_depth);

I'm puzzled by this: how is it supposed to work?  The pitch is the distance, 
in bytes, between a line pointer and the next one.

+   /* Update frame buffer with screen contents.  */
+   ASSERT(blitter_func);
+      
+   for (ty = sy; ty < sy+sh; ty++) {
+      src_rect.data = _xwin.screen_line[ty] + src_rect.pitch * sx;
+      dest_rect.data = _xwin.buffer_line[ty] + dest_rect.pitch * sx;
+      XWIN_BANK_SWITCH(ty);
+      blitter_func(&src_rect, &dest_rect);
+   }

Now I understand: you invoke the colorconv blitter once for each line.  We 
can probably do better in most cases.

> if it turns out that xwindows visuals are BGR for everyone, there wouldn't
> be much sense in adding support for the generic color-conversion. that
> doesn't mean i can try speeding up the existing fast visual methods
> though.

X-Window visuals can be pretty much anything, so you can't assume anything to 
be portable.  I suspect that the order is RGB on Sun workstations.  And we 
don't need to add anything, xwin.c is complete AFAIK; simply we can 
short-circuit it in the usual cases.

> also attached is timings with and without the patch. just to give you all
> an idea on how fast it is possible to make the color conversion. all
> best-case of course.

You can use misc/cmplog.pl to produce relative results.

> Take a look at _xwin_private_fast_palette_16_to_32 for instance, where the
> destination is not 8 bit, but in fact 32 bit. What puzzles me is that the
> visual can be paletted but not 8 bit.

Indeed, thanks for the correction.  Maybe 12-bit or 16-bit paletted visuals 
existed in the old days.

-- 
Eric Botcazou