Work on WineQuartz for MacOSX

[Roderick Colenbrander]

On Tue, May 18, 2010 at 3:12 PM, Mike Kronenberg
<mike.kronenberg at kronenberg.org> wrote:
> On 17.05.2010, at 07:52, Charles Davis wrote:
>
>> On 5/16/10 9:04 PM, James Mckenzie wrote:
>>> Roderick Colenbrander wrote:
>>>> On Sun, May 16, 2010 at 6:02 PM, C.W. Betts <computers57 at hotmail.com> wrote:
>>>>> On May 16, 2010, at 9:31 AM, James Mckenzie wrote:
>>>>>> All:
>>>>>>
>>>>>> There was or is a quite lengthy thread on this project.
>>>>>>
>>>>>> What is the status of work?  Any progress on Emmanuel's work from 2008?
>>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>> James McKenzie
>>>>>>
>>>>> If memory serves, the main reason why there hasn't been any work done is because of the
>>>>> dependency of Objective-C, which the project administrator has said "no" to.
>>>>>
>>>> The fact that Cocoa is objective C is one of the issues (Charles Davis
>>>> made some C wrapper I think). The most problematic thing is that it
>>>> really need is a DIB engine. The Cocoa graphics APIs are similar to
>>>> Cairo / XRender / Direct2D and other modern APIs. These APIs are great
>>>> for vector drawing, alpha blending and other fancy operations but they
>>>> are not low-level 2D APIs. For instance they lack most classic
>>>> (bitwise) 2D ROPs. The classic rendering stuff (Windows 7 does it this
>>>> way as well) has to be performed in software by a DIB engine.
>>>>
>>>> Roderick
>>>>
>>> Charles Davis did not 'make a c wrapper', Apple did.
>> Actually, he was referring to my tool for autogenerating C wrappers. I
>> haven't been working on it much, but I'll have it ready for you guys soon.
>>> However you are more correct in that we need a fully functional DIB engine in order to fully move the Apple interface from X11 to Aqua.
>> I agree. We need a DIB engine. Quartz by itself doesn't support
>> low-level raster operations (it's a vector engine).
> I did several implementations for the QEMU video output under OS X.
> The main grieve was Apple depreciating the QuickDraw API in 10.4 and removing it with 64bit. With this public direct buffer access gone, we did a quartz and a OpenGL implementation later. In the end, the OpenGL implementation won, as it was more portable, flexible and scaling comes for free (Fullscreen support).
> Basically one does the pixel manipulation in a buffer and loads that buffer as a texture at a fixed refresh rate (25/30/60hz?) if necessary. With Apples Client Storage and Texture Ranges [1], it proved to be the fastest pixel manipulation method and was very close to QD.
> Having a OpenGL based dib engine would work great with other OpenGL parts of wine (directx comes to mind) and it's open for porting.
>
> The OpenGL Code is still there, but I did not yet look at the current dib engine, yet. Any sparring partner?
> Mike
>
> [1] http://developer.apple.com/mac/library/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_texturedata/opengl_texturedata.html
>
>
>

The DIB engine has to be implemented in software. Important parts of
the DDB engine can be implemented using OpenGL. Parts which can be
implemented are things like BitBlt SRCCOPY, ColorFill, alpha blending
and some others it is similar to what Win7 accelerates and what APIs
like Cairo, XRender and others offer.

Writing a DIB engine is not a trivial job and Alexandre has also said
a couple of times (for instance at WineConf) that not much people are
capable of it because it encompasses so much. I think only he and Huw
are capable at this point. Though in the Win7 design (if we would go
for that) the DIB engine is less complex as even most DDB operations
(except for the few common ones I mentioned) are done in software.

Roderick