Re: WIne DIB
Ben Klein wrote: > Stop making new threads about this! We've already had too many DIB > Engine threads! > > > +1. Please keep all of the traffic on the DIB engine to one thread. James McKenzie
Re: WIne DIB
Stop making new threads about this! We've already had too many DIB Engine threads!
Re: DIB engine
2009/5/30 Dan Kegel : > If you're looking for something better specified, try finishing off > gdiplus. That's a somewhat well defined graphics package, > and Wine's implementation has a few missing bits yet, last > I checked. OH YES PLEASE. (lots of apps missing bits of this - check over bugzilla and everything in it that's been stubbed) - d.
re: DIB engine
Stephan Rose wrote: > My ears perked up when the two words DIB and spec were put > together in the same sentence. One frustration I encountered > when wanting to contribute to wine a little over two years ago > was that nobody seemed to be able to say "Hey, this is what > we are missing/need, here are the specs, go implement". >... > So if anyone can drop a full spec into my lap which outlines > everything I need to write and where (given I adhere to things > as I should of course) I won't have any issues getting that accepted later > on... I don't think such manna is likely to fall from heaven any time soon. If it was that easy to spec, we would have been done by now. If you're looking for something better specified, try finishing off gdiplus. That's a somewhat well defined graphics package, and Wine's implementation has a few missing bits yet, last I checked. - Dan
WIne DIB
On 05/30/2009 12:59 PM, wine-devel-requ...@winehq.org wrote: > Ben Klein ha scritto: > >> >> You would be surprised at how much of Wine is NOT a hack internally. >> Wine doesn't do hacks, > > Well, well there are some, indeed. > Of course, it's better not add new ones :-) > > hence AJ's reluctance to include the current >> DIB proposal in Wine (to make it "correct" later will require a lot of >> hacking, as Max has objected). > > Again, my engine isn't a hack. Nor you'll need hacks to embed it on > gdi32. > Even more, some parts will be simplified because of direct access to > internal > gdi32 structures, which can't be done (without hacks) in current > implementation. > The *only* semi-hack is the direct access of gdifont struct from > inside winedib > it could also be avoided, but with much useless code added. > Useless because it will be so once embedded in gdi32. >> >>> Do we even have an architectural document or guidelines to reference? >> >> This was also raised on the existing thread. No. This is a problem. >> The best we have so far is "DIB engine should be integrated into >> GDI32". This is not a problem, because both Max and AJ share this >> goal, but if I understand correctly, Max doesn't want to invest the >> effort (which is a lot) until the current design is validated by >> inclusion into upstream source. > > You got exactly the point :-) > To be precise, the effort isn't so huge, but summed with the effort of > maintaining > all in sync with current tree the global effort would be great (and > dumb, imho). >> >> >> Welcome aboard! I suggest that if you'd like to help out with the DIB >> engine (with the goal of getting it included to Wine upstream source), >> that you take a look at the code on bugzilla page #421 and talk to >> Massimo about how you might adapt it for integration into GDI32. >> > There's not too much to adapt moving the engine inside gdi32 is > (IMHO) > not complicated at all. More a writing effort than a coding one. > But, *before*, I guess winex11.drv (and any possible driver that does > DIBs internally) > should be patched stripping DIB handling *and* adding some stuffs for > mixed transfers. > Again, not an huge work, for somebody that knows well drivers internals. > It could also be done later, if wished... but logically that would be > the first step. > > Ciao > > Max > > Ok Max then document what you think the effort would be and what is needed to migrate your DIB engine into GDI32 Then We could send it to AJ for approval and go from there. This would be documenting the Delta which should allow AJ to go line item by line item and say yes or no to each or what needs to do. How long would that take you to do Max? Once that is done we would have a defined plan etc and going forward it would be documented. Chris
Re: Wineconf 2009 and funding
On Sat, May 30, 2009 at 11:30 AM, Austin English wrote: > Like Steven/Roderick said, we can increase that quite a bit if we > start fundraising early (now). I and Aleksey Bragin will be attending to represent ReactOS. I've asked their developers, users and advocates to contribute a little change to both projects donation links. I think this is a good chance for those of us with relationships to other projects that directly affect or benefit from Wine to contribute something back. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: d3d10: Improve parse_fx10.
2009/5/30 Stefan Dösinger :
>
> Am 30.05.2009 um 07:24 schrieb Dmitry Timoshkov:
>
>> "Rico Schüller" wrote:
>>
>>> - /* version info? */
>>> - skip_dword_unknown(&ptr, 2);
>>> + /* Compiled target version (e.g. fx_4_0=0xfeff1001,
>>> fx_4_1=0xfeff1011). */
>>> + read_dword(&ptr, &e->version);
>>> + TRACE("Target: %#x\n", e->version);
>>
>> 0xfeff/0xfffe is a unicode byte order mark, could it serve the same
>> purpose here?
>
> On top of my head I think it is the shader type marker - pixel shader,
> vertex shader, geometry shader. I don't have the headers atm, so I can't
> check to be sure.
>
Yes, but for effects. SM1-3 version tokens are 0xfffexxyy/0xxxyy
for vertex and pixel shaders resp. SM4 version tokens look like
0x00xy/0x000100xy/0x000200xy for PS/VS/GS. I don't remember what
the version token for d3d9 effects looks like, but this is consistent
with MS's general scheme for D3D/shader file formats.
Re: Wineconf 2009 and funding
On Sat, May 30, 2009 at 10:21 AM, Jeremy White wrote: >> What is the status of the Wine Party Fund this year, to help with the >> cost of transportation/lodging? I remember quite a bit of it was used >> up last year... >> > > I see no reason to change the practice of providing travel sponsorships. > > I believe the WPF is lower this year than last, so we may be more restrained > in what we can offer, but folks should definitely ask me if they're > interested. Like Steven/Roderick said, we can increase that quite a bit if we start fundraising early (now). -- -Austin
Wineconf 2009 and funding
> What is the status of the Wine Party Fund this year, to help with the > cost of transportation/lodging? I remember quite a bit of it was used > up last year... > I see no reason to change the practice of providing travel sponsorships. I believe the WPF is lower this year than last, so we may be more restrained in what we can offer, but folks should definitely ask me if they're interested. Cheers, Jeremy
Re: d3d10: Improve parse_fx10.
Am 30.05.2009 um 07:24 schrieb Dmitry Timoshkov:
"Rico Schüller" wrote:
-/* version info? */
-skip_dword_unknown(&ptr, 2);
+/* Compiled target version (e.g. fx_4_0=0xfeff1001,
fx_4_1=0xfeff1011). */
+read_dword(&ptr, &e->version);
+TRACE("Target: %#x\n", e->version);
0xfeff/0xfffe is a unicode byte order mark, could it serve the same
purpose here?
On top of my head I think it is the shader type marker - pixel shader,
vertex shader, geometry shader. I don't have the headers atm, so I
can't check to be sure.
Re: DIB engine
Ben Klein ha scritto: You would be surprised at how much of Wine is NOT a hack internally. Wine doesn't do hacks, Well, well there are some, indeed. Of course, it's better not add new ones :-) hence AJ's reluctance to include the current DIB proposal in Wine (to make it "correct" later will require a lot of hacking, as Max has objected). Again, my engine isn't a hack. Nor you'll need hacks to embed it on gdi32. Even more, some parts will be simplified because of direct access to internal gdi32 structures, which can't be done (without hacks) in current implementation. The *only* semi-hack is the direct access of gdifont struct from inside winedib it could also be avoided, but with much useless code added. Useless because it will be so once embedded in gdi32. Do we even have an architectural document or guidelines to reference? This was also raised on the existing thread. No. This is a problem. The best we have so far is "DIB engine should be integrated into GDI32". This is not a problem, because both Max and AJ share this goal, but if I understand correctly, Max doesn't want to invest the effort (which is a lot) until the current design is validated by inclusion into upstream source. You got exactly the point :-) To be precise, the effort isn't so huge, but summed with the effort of maintaining all in sync with current tree the global effort would be great (and dumb, imho). Welcome aboard! I suggest that if you'd like to help out with the DIB engine (with the goal of getting it included to Wine upstream source), that you take a look at the code on bugzilla page #421 and talk to Massimo about how you might adapt it for integration into GDI32. There's not too much to adapt moving the engine inside gdi32 is (IMHO) not complicated at all. More a writing effort than a coding one. But, *before*, I guess winex11.drv (and any possible driver that does DIBs internally) should be patched stripping DIB handling *and* adding some stuffs for mixed transfers. Again, not an huge work, for somebody that knows well drivers internals. It could also be done later, if wished... but logically that would be the first step. Ciao Max
