Closed Bug 488910 Opened 12 years ago Closed 12 years ago

StretchDIBits takes too long - Direct Draw


(Core :: Widget: Win32, defect)

Windows CE
Not set





(Reporter: blassey, Assigned: vlad)





(3 files)

+++ This bug was initially created as a clone of Bug #484864 +++

On windows mobile, we use StrechDIBits to draw to the screen:

During testing of Fennec, panning appears very sluggish.  When I profiled drawing, i found that calls to StretchDIBits take, on average, 98ms to redraw the entire HTC Touch Pro screen (480 x 640 pixels).

We really need to get this time down as it has a huge impact on fennec usability.

This bug will track solving this problem using direct draw
Latest DDraw patch from bug 484864, with license header copyrights switched to NVIDIA.
Attachment #373674 - Flags: review+
Small bugfix to use 0 instead of 0xff000000 for OPERATOR_CLEAR, to get transparent black if we ever have an ARGB surface.
Attachment #373675 - Flags: review+
The DirectDraw headers that come with the CE5 Standard SDK are different than the ones from Windows Mobile 6 and CE6.  It looks like WM6/CE6 took IDirectDraw4 and IDirectDrawSurface5 and called them IDirectDraw and IDirectDrawSurface, dropping support for the older ones (and breaking source compat in the process).

We could probably support both header types if we did a bunch of QI's all over the place, and some ifdefs to get the right GUID, but I started working on that and it just wasn't worth it.  Instead we just check to make sure we have the right header/lib in configure and the c file, giving an error message if we don't find the one we want.
Attachment #373679 - Flags: review+

Gonna call this resolved for now, though there are optimizations to ddraw coming -- should probably put those patches in new bugs.
Closed: 12 years ago
Resolution: --- → FIXED
Flags: in-testsuite-
Target Milestone: --- → mozilla1.9.2a1
Assignee: nobody → vladimir
You need to log in before you can comment on or make changes to this bug.