Il 24/12/2011 08:59, Alexandre Julliard ha scritto:
Massimo Del Fedele writes:
So, the question : have I understood right from changelogs and text is completed
in DIB engine, so I can help to make it a bit faster, or it's still missing
something so I should just wait ?
Text is done.
As I've got no idea of the status of DIB engine, besides looking at changelogs,
I'd like to know it... at least to see if there's some need of help.
The stuff that interests me at most is, as usual, the display speed of
autocad with embedded truetype fonts (aka bug 13801), which depends deeply
on
I introduced exactly the same on my old DIB engine, to avoid tons of FIXMES :-)
I find it quite useful.
Max
Il 25/07/2011 10:20, Huw Davies ha scritto:
On Sun, Jul 24, 2011 at 07:10:46PM +0300, Octavian Voicu wrote:
Disclaimer: these comments are based only on what I gather from
following commits and looking at the code, so can't guarantee it's
100% accurate; Huw or Alexandre would know better.
This
Il 24/07/2011 19:32, James McKenzie ha scritto:
On 7/24/11 10:14 AM, Massimo Del Fedele wrote:
Yep, true Autocad would gain benefit just with fonts. If fonts are not
implemented, that's useless by now.
Max:
It might be worthwhile to rebase your code on the fixes inputted by Huw so
Yep, true Autocad would gain benefit just with fonts. If fonts are not
implemented, that's useless by now.
Thank you for your answer waiting for better times, so :-)
Max
Having seen many patches related to DIB engine lately, I built latest
sources and tried it No speed enhancements on AutoCAD, my test app.
So, I wonder if the engine is already working, at least partially, or not.
If yes, there's some switch/environment variable to enable it ?
Sorry for asking
Il 24/05/2010 02:39, Dan Kegel ha scritto:
I've long predicted that companies might use Wine
for a while to ship Linux-compatible products,
and later switch to a native build once they know
they have users. Well, now we have at least one
example of this: Bricscad (see http://www.bricsys.com ).
James Mckenzie ha scritto:
wine-b...@winehq.org ha scritto:
http://bugs.winehq.org/show_bug.cgi?id=20505
Vitaliy Margolen changed:
What|Removed |Added
Status|RESOLVED
wine-b...@winehq.org ha scritto:
http://bugs.winehq.org/show_bug.cgi?id=20505
Vitaliy Margolen changed:
What|Removed |Added
Status|RESOLVED|CLOSED
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
James Mckenzie ha scritto:
Luke:
Heh, I wonder if someone should approach Autodesk and say, "Give us
sponsorship and we'll get Autocad running on Linux" they surely have
deep pockets :)
If Autodesk were interested in making AutoCad work with Linux, they would make
a native version, not try to
HI Ben,
Ben Klein ha scritto:
Of course, it also makes it more difficult to maintain, with any
change in gdi32 needing to be mirrored in the forked DIB engine, but
that's where git cherry-picking can come in handy :)
Done for about 3 monthes, no more time for it :-)
What I was trying to sa
Ben Klein ha scritto:
A little while ago I was trying to run an app that uses Win16 DIB.DRV
(I forget which app it was). My research indicated that although
DIB.DRV was an actual driver (similar in architecture to Max's
proposed DIB engine) in Win16 systems, in Windows 95 the functionality
was
Dmitry Timoshkov ha scritto:
"Massimo Del Fedele" wrote:
The driver loading mechanics is the gdi32 one duplicated in winedib.drv.
winedib.drv just intercept DIB calls and forward others to *any* other
driver. Again, in my thoughts that is a "transient" phase, at the en
Alexandre Julliard ha scritto:
The last time I rejected a simple patch from Massimo, he basically said
that he didn't have time to fix the patch and just dropped it. That
doesn't encourage me to spend more effort on reviewing his more complex
stuff.
Hi again :-)
Well, to be precise those wer
Alexandre Julliard ha scritto:
Hi Alexandre,
One of the main problems I see is that your design is based on the
premise that there's only one graphics driver, the X11 driver.
Well, I guess I expressed myself not completely corrected.
My engine do load the winex11 exactly as gdi32 does.
That
Alexandre Julliard ha scritto:
Well, the prototype doesn't show much evidence of a good design. Maybe
Massimo has one in mind, but he hasn't explained it so far.
Well, I still think that the "goodness" of a design is a matter of taste.
My design is *a* design, started because of a personal ne
Steven Edwards ha scritto:
On Sun, May 24, 2009 at 10:19 PM, James McKenzie
wrote:
That's ugly. Did you attempt to type in something in the Document area?
I've disabled all my Quartz hacks, the only thing sort of non-standard
I have is my custom FreeType with patented engine enabled and supp
André Hentschel ha scritto:
Massimo Del Fedele schrieb:
André Hentschel ha scritto:
I dont know anything about that, but may it be possible to compile
your code to a standalone driver for seperate download?
It would be great to just install a DIB-Driver for wine.
Sorry if that was a stupid
André Hentschel ha scritto:
I dont know anything about that, but may it be possible to compile your
code to a standalone driver for seperate download?
It would be great to just install a DIB-Driver for wine.
Sorry if that was a stupid idea.
The idea is not stupid at all :-)
I was thinking to d
Kai Blin ha scritto:
On Sunday 24 May 2009 06:54:10 Ben Klein wrote:
Does that mean it's time to remove these todos (and make them full
tests) or are they still wanted for the case where Max's DIB engine is
not installed?
They are full tests, they're just marked as not passing in wine. Which
Ben Klein ha scritto:
2009/5/24 Massimo Del Fedele :
Austin English ha scritto:
On Fri, May 22, 2009 at 6:31 PM, Massimo Del Fedele
wrote:
I posted on bug 421 page (as usual) latest update of my engine.
It suld pass all tests in wine suite also all bitmap's todo_wines,
so expect
Austin English ha scritto:
On Fri, May 22, 2009 at 6:31 PM, Massimo Del Fedele wrote:
I posted on bug 421 page (as usual) latest update of my engine.
It suld pass all tests in wine suite also all bitmap's todo_wines,
so expect some "false positive" signaled by tests.
Au
I posted on bug 421 page (as usual) latest update of my engine.
It suld pass all tests in wine suite also all bitmap's todo_wines,
so expect some "false positive" signaled by tests.
Austin, could you please re-run it on your test machines ?
Ciao
Max
Giuseppe Bilotta ha scritto:
I've started testing your patches (btw, the 9th patch in your series
is missing the 0009- prefix although the 'series' file claims it
should have;
ops that was the hurry. stgit don't put the prefix, I added it manually
just for who don't want to use it
also,
Well, it seems that the engine fixes some unrelated bugs too :-)
Bugs 15146 and 10408, as reported by a tester.
BTW In a couple of weeks all (few) remaining failing tests should be fixed.
Then I'll try to optimize somehow the mixed blitting, which is the only
stuff that remains slower than origin
Michael Karcher ha scritto:
Am Sonntag, den 17.05.2009, 17:35 +0200 schrieb Massimo Del Fedele:
1) Some color on monochrome bitmaps here I guess nobody knows how to do it
right. I fixed some todo wine (most) but have 2 failures which wine does right.
Seldom used anyways, and happens only
Austin English ha scritto:
On Sun, May 17, 2009 at 10:35 AM, Massimo Del Fedele wrote:
Austin, could you please retest it against test suite ?
I've ran it, but it doesn't appear to be showing up on
test.winehq.org. I'll investigate why when I get a bit more time.
P.S., ther
Remaining bugs are related to :
1) Some color on monochrome bitmaps here I guess nobody knows how to do it
right. I fixed some todo wine (most) but have 2 failures which wine does right.
Seldom used anyways, and happens only on weird palettes. I guess not ever
Microsoft knows what they did
Zachary Goldberg ha scritto:
On Thu, May 14, 2009 at 5:01 AM, Massimo Del Fedele wrote:
Giuseppe Bilotta ha scritto:
On Thursday 14 May 2009 02:02, Massimo Del Fedele wrote:
I started fixing failures against test suite.
Most of bitmap ones are fixed, remaining are due
to still stubbed funcs
Giuseppe Bilotta ha scritto:
On Thursday 14 May 2009 02:02, Massimo Del Fedele wrote:
I started fixing failures against test suite.
Most of bitmap ones are fixed, remaining are due
to still stubbed funcs.
Now the problem is that it fixed also most todo_wines on bitmap suite
As usual, on
I started fixing failures against test suite.
Most of bitmap ones are fixed, remaining are due
to still stubbed funcs.
Now the problem is that it fixed also most todo_wines on bitmap suite
As usual, on bug 421 page for who wants to test it.
Ciao
Max
Scott Ritchie ha scritto:
As a packager, as long as Massimo is willing to keep the patches
applying to the latest version and user-optional to enable, I'd be
willing to bundle em. I'm normally averse to keeping deltas with
Alexandre's main branch other than backports, but this one is
specifi
Austin English ha scritto:
On Sun, May 10, 2009 at 5:19 AM, Massimo Del Fedele wrote:
Massimo Del Fedele ha scritto:
Well, after some (many) bugfixes and additions, the mighty DIB Engine is
almost 100%
operational.
On one of tested apps (MSN Messenger) it behaves even better than original
one
Austin English ha scritto:
Perhaps a wine-experimental branch, with applicable warnings?
Getting a bunch of people to test it may give us good data on how much
it improves things, which is currently lacking.
That one should be maintained too not a difficult task but
a time consuming one.
Henri Verbeet ha scritto:
2009/5/11 Joerg Mayer :
As I think that Alexandre has stated his preference (and I can understand
him taking a long term view), I want to ask the packagers for the distros
out there: Would it be OK for you to add the necessary patch into the
code that you distribute. Pe
Joerg Mayer ha scritto:
So from the end users point of view Alexandre is refusing this solution which
is much better than what exists now into the official wine tree.
Ah, wait it's not "much better", is an alternative.
As it is now, it gives speed improvement for some apps, and probably
s
Roderick Colenbrander ha scritto:
Unfortunately getting this code into Wine is not really possible
(Alexandre would like to see Huw finishing the design and all the work
but no time has been assigned to him for this) BUT I think work on
this DIB engine even if it won't make it in Wine isn't was
James McKenzie ha scritto:
Good work. Have you started to think about how to get this into Wine
where AJ will approve?
James McKenzie
Ah, I'm not very optimistic that it'll ever enter on wine tree :-)
Nor have I time to adopt the "trial and error" way up to it's
approved.
The easiest way I
Warren Dumortier ha scritto:
2009/5/10 Massimo Del Fedele :
Massimo Del Fedele ha scritto:
Well, after some (many) bugfixes and additions, the mighty DIB Engine is
almost 100%
operational.
On one of tested apps (MSN Messenger) it behaves even better than original
one :-)
For whom wish to test
Massimo Del Fedele ha scritto:
Well, after some (many) bugfixes and additions, the mighty DIB Engine is
almost 100%
operational.
On one of tested apps (MSN Messenger) it behaves even better than
original one :-)
For whom wish to test it, bug 421 page.
Ciao
Max
fixed also last
Well, after some (many) bugfixes and additions, the mighty DIB Engine is almost
100%
operational.
On one of tested apps (MSN Messenger) it behaves even better than original one
:-)
For whom wish to test it, bug 421 page.
Ciao
Max
Roderick Colenbrander ha scritto:
Have you also tried to use the GDI AlphaBlend function? This is the
one which should be used I think and we back it by XRender ..
Roderick
Sorry for the OT :
apropos AlphaBlend and RGBA bitmaps... what happens with BitBlt on
a destination DIB which has al
Vincent Povirk ha scritto:
This is by design. Each call to ok() is an individual test,
independent of the others, and todo_wine marks them all as todo.
If you have the same code running multiple tests, you can mark some of
them as todo by putting a todo flag in your data.
If you really want mul
Today writing a testcase I found a "problem" on todo_wine construct.
In short :
void first_test_part()
{
ok(test1(), "failed\n");
}
void second_test_part()
{
ok(test2(), "failed\n");
}
todo_wine
{
first_test_part();
second_test_part();
}
this "fails" (i.e. is marked as passing inside
Luke Benstead ha scritto:
2009/5/1 Massimo Del Fedele :
Luke Benstead ha scritto:
2009/5/1 Scott Ritchie :
Massimo Del Fedele wrote:
I put on bug's 421 page an update of my dib engine.
It implements AlphaBlend, StretchBlt and has many color fixes.
If you want to try it, just f
Luke Benstead ha scritto:
2009/5/1 Scott Ritchie :
Massimo Del Fedele wrote:
I put on bug's 421 page an update of my dib engine.
It implements AlphaBlend, StretchBlt and has many color fixes.
If you want to try it, just follow instructions on above page.
Ciao
Max
Keep at it, it&#
http://www.winehq.org/pipermail/wine-patches/2009-April/072442.html
http://www.winehq.org/pipermail/wine-patches/2009-April/072452.html
Ciao
Max
Nikolay Sivov ha scritto:
Massimo Del Fedele wrote:
Massimo Del Fedele ha scritto:
Should work for both DIBs and DDBs format, but strange enough the
IPicture bitmap
inside wine gdiplus bitmap is always a 32 bit DDB by now... haven't
found any
other case.
Ciao
Henri Verbeet ha scritto:
I would of
course expect Alexandre to be much more strict wrt. winex11.drv than
wined3d since it's a much more critical component.
of course :-)
I'd also expect
reputation / experience with winex11.drv and gdi32 to be taken into
account. I.e., trust, if you like.
Reece Dunn ha scritto:
2009/4/28 Massimo Del Fedele :
My personal final thoughts
1) It's obvious (but then, why we're repeating it forever ?) that
final result is : DIB inside gdi32 and DDBs inside X11, with
probably DIB cached to DDBs in x11 for performance reasons.
A
My personal final thoughts
1) It's obvious (but then, why we're repeating it forever ?) that
final result is : DIB inside gdi32 and DDBs inside X11, with
probably DIB cached to DDBs in x11 for performance reasons.
2) Assuming point 1, the *only* problem is to decide how get
to it, so choose
Roderick Colenbrander ha scritto:
No then you don't have the engine yet. In my proposal you would first
make winex11.drv not depend on DIBs (the conversion code would still
be in winex11.drv),
uhmmm... and in the meanwhile where would be DIB processed ?
then you move the conversion code ove
Roderick Colenbrander ha scritto:
We shouldn't introduce a temporary driver.
Why ?
I can't speak for Alexandre
but I think he would prefer to let winex11.drv not directly touch DIBs
and move it to gdi32
Me too
and I guess in a second step also move the
conversion code over to gdi32
Jesse Allen ha scritto:
On Tue, Apr 28, 2009 at 8:13 AM, Massimo Del Fedele wrote:
2) when winedib.drv is working good enough, wanted to "detach" it from
winex11.drv, so make another "driver" comprising DDB parts of wineX11
and all optimizations needed.
This detachi
Roderick Colenbrander ha scritto:
Hi,
Massimo demonstrated the need for a DIB engine for Autocad but the way
it is implemented is not fully correct. We already talked a bit about
that on IRC. He is right that it should be implemented inside gdi32
and that it should be done in small steps (where
Hi all,
I was thinking just yesterday to a temporary solution that could, maybe, be
useful without "disturbing" wine main workflow.
My new approach has the structure of an "independent" driver which, even if
it uses winex11 for DDB processing, is seen as a completely separated driver
by gdi32.
By
The regression is completed by this one :
-Second regression : Don't show second registration page and help contents
8d28f09d8a582ff499b5947a5a2d1cf2700fb259 is first bad commit
commit 8d28f09d8a582ff499b5947a5a2d1cf2700fb259
Author: Jacek Caban
Date: Tue Dec 30 06:48:59 2008 +0100
m
Following patch
c3bdda810243ed6c8d6b9960d1df3b534653b438 is first bad commit
commit c3bdda810243ed6c8d6b9960d1df3b534653b438
Author: Jacek Caban
Date: Wed Sep 24 18:19:46 2008 +0200
mshtml: Use ActiveScript for JavaScript in file protocol documents.
:04 04 61b72d076d5bcefd2ec1938
Austin English ha scritto:
On Sat, Apr 25, 2009 at 12:56 PM, Massimo Del Fedele wrote:
In riched20/writer.c the font table was erroneously streamed out with a \r\n
after
each font, instead of end of font table. Can be easily checked on rtf output
from windows. AutoCAD 2005 was very picky with
I put on bug's 421 page an update of my dib engine.
It implements AlphaBlend, StretchBlt and has many color fixes.
If you want to try it, just follow instructions on above page.
Ciao
Max
Dylan Smith ha scritto:
This can easily be tested by saving a rich text document in wordpad. The
rich text will always be null terminated, unlike plain text files which
will not have a terminating null byte.
I noticed in a bug 14827 that AutoCAD 2005 looked for this NULL byte to
determine the le
Jesse Allen ha scritto:
I'm trying to understand what the problem is to make you think there
needs to be a change. Are most of the problems with Blt related
functions?
No
It is my understanding the DIB engine should actually be able to call
the display driver and vice-versa. So I think we
Ben Klein ha scritto:
Are there any cases like that where the sourcecode of the app is available?
I see it much more useful to track the call stack inside wine, not in the app.
In my app there's a crash that's triggered after many wine calls, and this
was useful to track them down up to cal
Today I found this :
#include "execinfo.h"
void BT(void)
{
void *array[50];
size_t size;
char **strings;
size_t i;
size = backtrace (array, 50);
strings = backtrace_symbols (array, size);
printf ("Obtained %zd stack frames
Jesse Allen ha scritto:
What about other drivers? Is the DIB driver going to know how to
handle the others then?
The engine act as a filter between gdi32 and the DISPLAY driver, other stuffs
are untouched.
The changes on gdi32 are just to "prefere" the loading of the engine instead of
nor
Reece Dunn ha scritto:
2009/4/14 Massimo Del Fedele :
The approach taken so far consisted in having 2 device pointers inside
GDI32, one for dib engine and
the other for normal display driver.
This way had the disadvantage of having to keep in sync the DC with the
right driver depending on
The approach taken so far consisted in having 2 device pointers inside GDI32,
one for dib engine and
the other for normal display driver.
This way had the disadvantage of having to keep in sync the DC with the right
driver depending on
selected bitmap, which lead to many small changes spread alo
Alexandre Julliard ha scritto:
- descr.bits = bits;
+ descr.bits = (BYTE *)bits + widthBytes * (tmpheight > 0 ? (height -
startscan - lines) : startscan);
You shouldn't need to change the bits address.
After a deeper look at it, I think there's no other (simple) way to do it.
Us
Massimo Del Fedele ha scritto:
Changes from previous one :
bits shifting displaced from X11DRV_SetDIBits() to
X11DRV_DIB_SetImageBits()
Result is identical to former, the patch looks worse to me than before,
but
As a note, there's no way to leave 'descr->bits' untouched
Massimo Del Fedele ha scritto:
p.s.: of course, it needs also
widthBytes * (.)
I just shorted it to show the problem :-)
Ciao
Max
Alexandre Julliard ha scritto:
Massimo Del Fedele writes:
- descr.bits = bits;
+ descr.bits = (BYTE *)bits + widthBytes * (tmpheight > 0 ? (height -
startscan - lines) : startscan);
You shouldn't need to change the bits address.
Well, original code was
de
Massimo Del Fedele ha scritto:
But then, I'm still not sure IF GetGlyphOutlineW does return GDI_ERROR
when called with GGO_GLYPH_INDEX flag (msn is not clear about...) nor I
know how to make a call to GetGlyphOutlineW() requesting a buffer size
which simulates an error. I could do w
Alexandre Julliard ha scritto:
GDI_ERROR is clearly not a valid buffer size, and must be checked
for. Please write test cases like Dmitry suggested.
Yep, right, GDI_ERROR is -1L, too large to be a buffer size.
Uhmmm... the only non-graphical testcase that occours to me is one
showing that Ge
Dmitry Timoshkov ha scritto:
"Massimo Del Fedele" wrote:
This patch doesn't match the normal logic of ExtTextOut implemented
in dlls/winex11.drv/xrender.c, also this requires a test case for
both code paths.
Why ? As is it now PATH_ExtTextOut() simply returns FALSE on firs
Dmitry Timoshkov ha scritto:
"Massimo Del Fedele" wrote:
PATH_ExtTextOut() uses GetGlyphOutlineW() which can return a NULL
buffer size not just on errors but also on non-printable glyphs.
Instead of aborting the function should check for such cases, get the
metrics and continue.
I've gone a bit further with my DIB Engine, mostly on gdi32 side, in
order to solve the last problems, at least as seen in my favorite app,
Autocad 2005.
Previous version had a bug related to the *only* .net part of that app
(which was obviously written by a 5 years old child, imho), the layer
Massimo Del Fedele ha scritto:
> Hi,
>
> I made some changes to DIB engine :
>
> 1) Some more consistent DIB type naming and color handling
> 2) Partial implementation of 256 ROP3 operations
> 3) Partial ROP3 implementation on blitting (stil no pattern)
> 4) Some optimi
Dylan Smith ha scritto:
> These calls to ME_WrapMarkedParagraphs never do anything, and don't make
> sense to be called in these places. These places are for ME_MoveCaret,
> and ME_ArrowHome, which both don't involve any text being modified, and
> all (direct and indirect) calls to these functions
Evgeny Burzak ha scritto:
> Hello,
>
> I make some tests and it show interesting results:
> * Archicad 10 and 11 can open plans, crashed of course and unusable, but
> with WINEDIB=OFF it didn`t work at all.
> * Flash 8 with WINEDIB=ON render fonts much faster.
>
> Screens and logs attached.
>
Jesse Allen ha scritto:
> On Sun, Feb 1, 2009 at 9:29 AM, Massimo Del Fedele wrote:
>> As asked to me, I have separated the dib engine into a patchset, trying to
>> keep (when possible) the original author's submissions, so Huw Davies, Jesse
>> Allen and me.
>&g
As requested I separated the engine in small patches, trying to keep
original authors when possible.
As the post didn't appear here (problem with zipped files, maybe ?),
I've put it on bug 421 page.
I whish to know if it can be ok for including on wine tree.
Ciao
Max
i32/bitblt.c
@@ -2,6 +2,8 @@
* GDI bit-blit operations
*
* Copyright 1993, 1994 Alexandre Julliard
+ * Copyright 2007 Jesse Allen
+ * Copyright 2008 Massimo Del Fedele
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of
Jesse Allen ha scritto:
>
> The DIB engine is really unlikely to help starcraft the game at all.
> However, try staredit.exe ;)
>
> Jesse
>
The engine in its current state will, IMO, help just those apps that
don't require real time graphics but do make many drawings on dibs, so
requiring man
Reece Dunn ha scritto:
> 2009/1/27 Massimo Del Fedele :
>> Any opinion about this one ? Could it be a good candidate for inclusion
>> in wine tree ?
>
> Hi,
>
> I have used this with StarCraft, running it with and without the DIB
> engine enabled. I find the envi
Any opinion about this one ? Could it be a good candidate for inclusion
in wine tree ?
Ciao
Max
Erich Hoover ha scritto:
>
> What I was trying to say is if you could have something like this for
> all the stubs:
>
> BOOL DIBDRV_AlphaBlend( DIBDRVPHYSDEV *devDst, INT xDst, INT yDst, INT
> widthDst, INT heightDst,
> DIBDRVPHYSDEV *devSrc, INT xSrc, INT ySrc, INT
Erich Hoover ha scritto:
>
> I haven't looked into your implementation in much detail (I need more
> hours in a day, I swear), but would it be possible to pass all the stubs
> on so that unimplemented functionality still works even if it's dog
> slow? It'd be nice if we could take advantage of
Roderick Colenbrander ha scritto:
>>
>
> Having an environment variable is a minor detail. Sure it should
be used transparently but it will take a lot of time (when the
architecture is correct)
to enable it by default.
IMHO the engine will (if it ever enters on main trunk) stay disabled
by
Ben Klein ha scritto:
>
> I'm still opposed to adding an environment variable for something so
> simple (an enable/disable flag). It just seems like extra work for no
> benefit to me. I'm sure we can all agree that the registry is a
> suitable place for the setting.
The environment variable allow
I did some update on the engine, I tried to post it here as a zipped
patch, but didn't got published So I've put it on bug 421 page with
instructions on how to use it.
I'd like to have some feedback if the implementation way is the right one.
Ciao
Max
Dan Kegel ha scritto:
> http://www.rentacoder.com/RentACoder/misc/BidRequests/ShowBidRequest.asp?lngBidRequestId=1087309&txtFromURL=AId_512725
>
> Someone's got to break the bad news to him about the likely cost...
>
>
>
Uh... maybe he forgot some nulls on the end... :-)
Roderick Colenbrander ha scritto:
>> I haven't still any clue if the way I started the DIB engine has the
>> correct approach, I mean if I should follow this way with the hope to
>> have it included in main tree or not Can please somebody tell me
>> something about ?
>>
>> Ciao
>>
>> Max
>>
I haven't still any clue if the way I started the DIB engine has the
correct approach, I mean if I should follow this way with the hope to
have it included in main tree or not Can please somebody tell me
something about ?
Ciao
Max
Paul Vriens ha scritto:
> Massimo Del Fedele wrote:
>> Here the second part, it contains winedib.drv code and changes to
>> Makefiles.
>>
>> Still no way to enable/disable the engine, besides of deleting the .so
>> inside dlls/winedib.drv.
>>
>> I&#x
Jeff Zaroyko ha scritto:
> On Wed, Dec 24, 2008 at 11:23 AM, Massimo Del Fedele wrote:
>> Here the second part, it contains winedib.drv code and changes to Makefiles.
>>
>> Still no way to enable/disable the engine, besides of deleting the .so
>> inside dlls/winedib.dr
Austin English ha scritto:
> On Tue, Dec 23, 2008 at 10:44 AM, Massimo Del Fedele wrote:
>> As my DIB engine is becoming usable (I already use it on Autocad for my
>> job), I'm thinking to publish the patches.
>> As it's still not complete, I'm thinking to add
Roderick Colenbrander ha scritto:
>> As my DIB engine is becoming usable (I already use it on Autocad for my
>> job), I'm thinking to publish the patches.
>> As it's still not complete, I'm thinking to add a way to enable it on
>> demand with registry and environment variable :
>>
>> export WINED
As my DIB engine is becoming usable (I already use it on Autocad for my
job), I'm thinking to publish the patches.
As it's still not complete, I'm thinking to add a way to enable it on
demand with registry and environment variable :
export WINEDIB=ON activates it
export WINEDIB=OFF deactivates i
1 - 100 of 128 matches
Mail list logo
