[Mono-bugs] [Bug 666245] libgdiplus - fast copy path optimisations

bugzilla_noreply at novell.com bugzilla_noreply at novell.com
Mon Mar 28 14:41:21 EDT 2011



--- Comment #5 from Alexander Stohr <alexander.stohr at gmx.de> 2011-03-28 18:41:20 UTC ---
okay, got the point for the reply in this case.

so testing would require image copying cases designed by a matrix setup with
twice those axis for input and output format:

- 24 color bits (RGB888) and 8 bit alpha in a 32 bit container
- 24 color bits (RGB888) in a 32 bit container
- 24 color bits (RGB888) in a 24 bit container
- 16 color bits (RGB565) in a 16 bit container
- 15 color bits (RGB555) and 1 bit alpha in a 16 bit container
- 15 color bits (RGB555) in a 16 bit container
- 8 bit index value to what ever palette
- 4 bit index value to what ever palette
- 1 bit index value to what ever palette

if possible the results should be as well human readable (e.g. via a final PNG
as a side effect some performance values might drop out of that test case. ;-)

how to achive that testing even unveils memory boundary violaitons?
- a simple aproach would be to put some magic number boundaries aside to source
and destination buffers.
- a little more complex case would be the usage of some MMU based memory
protection facilities - if there is a granularity in this unit, then testing
could be done twice (or 2x2) with the image data on top and on bottom of the
valid space in between.

testing different width and heights including different source and destination
parameters should be on the list for deeper checking as well.

testing on different platforms would be fine, but i assume i will not have to
much choices right now here at location other than x86. so if it basically
works others have to jump in or some sort of remote access to alternate
architectures including compilers and a bit of disc space might be needed.

thats all just what the whish from above for a reasonable test set would mean.
and its only the pretty rough design.

Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.

More information about the mono-bugs mailing list