Closed GoogleCodeExporter closed 8 years ago
so the problem here is that we want to fix your thing without introducing the
following behavior:
1. request floating point color
2. no hardware support for floating point
3. you get reference device!
i'd rather it was,
1. request floating point color
2. no hardware support for floating point
3. request truecolor modes
4. no support
5. *maybe* drop to reference
reason its a maybe is that pixeltoaster promises to the user that it is going
to be
fast, i'd not want somebody to get a reference device when they were not
expecting to
so if you could add your reference device thing, make sure that it is done
after the
checking of all hardware available options
when you do, it should be floating point color if the user requested
FloatingPointColor output, or argb8888 if he requested TrueColor output
cheers
Original comment by glenn.fi...@gmail.com
on 23 May 2008 at 4:33
Hi Glenn,
I totally agree with the behavior you describe. I created a patch that works
OK on
that machine without a HAL device. It will only try the REF device when
everything
else fails. Funny enough, the REF device was not able to create the floating
point
device I was requesting, so it had to fall back on the argb8888 one.
This patch will automatically try the REF device if all else fails, but maybe
that's
not appropriate. Maybe it should only try the REF device when no HAL device is
present?
Bram
Original comment by bram.deg...@gmail.com
on 6 Jun 2008 at 11:54
Attachments:
This patch seems to work, except for this weirdest thing. The machine I'm
talking
about is a 64-bit windows 2003 server. When I compile and run the application
in
64-bit mode, the REF device is correctly created. But in 32-bit mode, even
this fails!
Original comment by bram.deg...@gmail.com
on 17 Jun 2008 at 11:21
I've commited the patch of comment 2 to the trunk (r143).
Original comment by bram.deg...@gmail.com
on 3 Jul 2008 at 5:59
Original issue reported on code.google.com by
bram.deg...@gmail.com
on 23 May 2008 at 8:58