Re: Bug 28791: ensure that dashes value is not 0 for PS_USERSTYLE linestyles
Just removing the zeros will shift the pattern to the left potentially producing an effect that is not expected. I will take a look at what happens on Windows to see what needs to be replicated. On 19 October 2011 20:05, Alexandre Julliard julli...@winehq.org wrote: damian dixon damian.di...@gmail.com writes: diff --git a/dlls/winex11.drv/pen.c b/dlls/winex11.drv/pen.c index b677515..71b1bea 100644 --- a/dlls/winex11.drv/pen.c +++ b/dlls/winex11.drv/pen.c @@ -108,7 +108,7 @@ HPEN X11DRV_SelectPen( PHYSDEV dev, HPEN hpen ) case PS_USERSTYLE: physDev-pen.dash_len = min(elp-elpNumEntries, MAX_DASHLEN); for(i = 0; i physDev-pen.dash_len ; i++) -physDev-pen.dashes[i] = min(elp-elpStyleEntry[i], 255); +physDev-pen.dashes[i] = min(elp-elpStyleEntry[i], 255) ? min(elp-elpStyleEntry[i], 255) : 1; Removing 0 entries (and merging the adjacent entries) would probably be more correct. It could also use some test cases. -- Alexandre Julliard julli...@winehq.org
Re: Problems with drawing text in 1.3.29
Thanks for the suggestions. I've narrowed one of the issues down to WineEngGetGlyphOutline in dlls/gdi32/freetype.c. The pitch is 6640 and the height is 53003. This means that a buffer of ~335Mb has been allocated and then memset. This is where the slow down is occurring (because of the memset). I suspect the resultant crash is also because of this. I would suggest that limits need to be placed on the maximum pitch and height. I do not however believe that this is the root cause just one of the symptoms. On 5 October 2011 18:37, Marcus Meissner mar...@jet.franken.de wrote: On Wed, Oct 05, 2011 at 04:53:18PM +0100, Damian Dixon wrote: Hi, I was attempting to use Wine 1.3.29 (in OpenSUSE 11.4 x86) and because of issues pulled the source from git last night and still have problems. I am having performance issues with DrawText (5 odd seconds to draw a simple string) and the occasional X Error and crash. The X Error is consistent and is as follows: fixme:advapi:SetSecurityInfo stub X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 151 (RENDER) Minor opcode of failed request: 17 (RenderCreateGlyphSet) Serial number of failed request: 41091 Current serial number in output stream: 41571 Process of pid=0023 has terminated The crash less consistent but is dependent upon the amount of text I attempt to draw. The last version I know this worked in was 1.1.39. I've a few things to still try out before I attempt to create an RBT. To get a backtrace and be able to dump some datastructures, run with WINEDEBUG=+synchronous wine foo.exe This will bring it into the debugger once the condition happens. CIao, MArcus
Solved: Problems with drawing text in 1.3.29
I have narrowed the issue down to a difference in behaviour between Windows and Wine. The problem boils down to the following code: NONCLIENTMETRICS ncm; memset(ncm, 0, sizeof(NONCLIENTMETRICS)); ncm.cbSize = sizeof(NONCLIENTMETRICS); VERIFY(SystemParametersInfo(SPI_GETNONCLIENTMETRICS, sizeof(NONCLIENTMETRICS), ncm, 0)); I used the font's returned from this call for drawing text and this caused the crash. The problem is that I upgraded to VS2010 and changed the target to WINVER=0x600. This means that I needed to change my code to the following. NONCLIENTMETRICS ncm; memset(ncm, 0, sizeof(NONCLIENTMETRICS)); ncm.cbSize = sizeof(NONCLIENTMETRICS); #if(WINVER = 0x0600) OSVERSIONINFO osvi; memset(osvi,0,sizeof(osvi)); osvi.dwOSVersionInfoSize = sizeof(osvi); GetVersionEx(osvi); if (osvi.dwMajorVersion 6) ncm.cbSize -= sizeof(ncm.iPaddedBorderWidth); #endif VERIFY(SystemParametersInfo(SPI_GETNONCLIENTMETRICS, sizeof(NONCLIENTMETRICS), ncm, 0)); Note: On windows my application does not actually crash or stop working with my original code and the text is displayed at a size I would kind of expect it to be. I will raise a bug for this one... as a difference in behaviour. On 7 October 2011 08:50, Damian Dixon damian.di...@gmail.com wrote: Thanks for the suggestions. I've narrowed one of the issues down to WineEngGetGlyphOutline in dlls/gdi32/freetype.c. The pitch is 6640 and the height is 53003. This means that a buffer of ~335Mb has been allocated and then memset. This is where the slow down is occurring (because of the memset). I suspect the resultant crash is also because of this. I would suggest that limits need to be placed on the maximum pitch and height. I do not however believe that this is the root cause just one of the symptoms. On 5 October 2011 18:37, Marcus Meissner mar...@jet.franken.de wrote: On Wed, Oct 05, 2011 at 04:53:18PM +0100, Damian Dixon wrote: Hi, I was attempting to use Wine 1.3.29 (in OpenSUSE 11.4 x86) and because of issues pulled the source from git last night and still have problems. I am having performance issues with DrawText (5 odd seconds to draw a simple string) and the occasional X Error and crash. The X Error is consistent and is as follows: fixme:advapi:SetSecurityInfo stub X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 151 (RENDER) Minor opcode of failed request: 17 (RenderCreateGlyphSet) Serial number of failed request: 41091 Current serial number in output stream: 41571 Process of pid=0023 has terminated The crash less consistent but is dependent upon the amount of text I attempt to draw. The last version I know this worked in was 1.1.39. I've a few things to still try out before I attempt to create an RBT. To get a backtrace and be able to dump some datastructures, run with WINEDEBUG=+synchronous wine foo.exe This will bring it into the debugger once the condition happens. CIao, MArcus
Problems with drawing text in 1.3.29
Hi, I was attempting to use Wine 1.3.29 (in OpenSUSE 11.4 x86) and because of issues pulled the source from git last night and still have problems. I am having performance issues with DrawText (5 odd seconds to draw a simple string) and the occasional X Error and crash. The X Error is consistent and is as follows: fixme:advapi:SetSecurityInfo stub X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 151 (RENDER) Minor opcode of failed request: 17 (RenderCreateGlyphSet) Serial number of failed request: 41091 Current serial number in output stream: 41571 Process of pid=0023 has terminated The crash less consistent but is dependent upon the amount of text I attempt to draw. The last version I know this worked in was 1.1.39. I've a few things to still try out before I attempt to create an RBT. However I would like to know if anyone else is experiencing similar problems and f they have solved the problem. Thanks Damian
Crash bug in Wine 1.3.5 in advapi32/service.c
Hi, In file dlls/advapi32/service.c, line 1135 a memory copy occurs, however the lpservicestatus is not checked to see if the value is NULL. This causes a crash in an application that has worked before under wine. My naive change is: if (ret lpservicestatus) memcpy(lpservicestatus, SvcStatusData, sizeof(SERVICE_STATUS)) ; Regards Damian
Windows Installer change in behaviour Wine 1.3.5.
Hi, I have installed my application under Wine 1.3.5 however with this version of Wine the registry is not updated by the installer. The registry entry ends up with the value '[INSTALL_DIR]'. Which is odd as it has worked before with older versions of Wine. I've not had the time to investigate but thought someone my be interested. Regards Damian
Re: implement PS_USERSTYLE handling - obviously not correct ;)
Hi Hans,
I have run the patch against my application and the line-styles draw as far
as I can tell are the same as on Windows when a single line segment where
the pixel width of one is used.
However when a polyline is drawn the dash style does not get drawn
correctly. There seems to be an issue with repeat of the style when the
pixel width of the line is increased. It looks like the style gets
multiplied up.
I've not looked too deeply into this, however it looks like all pen styles
are affected by the requested line width.
I also have an issue with the standard styles as they are defined as I
belive they are not correct. I'm comparing on a pixel to pixel basis between
Windows and Wine. However your patch does not affect this. I just wished to
make you aware. When I have a sample to demonstrate this I will raise a bug
report.
I've made some additional comments below on the patch and on the platforms
supporting PS_USERSTYLE.
In addition there is also the odd even count for the bits that needs to be
dealt with. However in most cases I doubt this would be an issue.
I'm also a bit of a newbie here and am not exactly sure how to advance this
patch.
I can create a simple Win32 test which demonstrates the behaviour I am
looking for. Of course the Windows results will be a screenshoot which will
have to be compared against the test running under Wine.
Where would I post this sample? (no guarentees on how long it's going to
take me as I'm still trying to write a series of alpha blend tests).
Regards
Damian
On Sat, Apr 4, 2009 at 9:49 PM, Hans Breuer h...@breuer.org wrote:
Hi,
just read again http://www.winehq.org/sending_patches and noticed that my
first wine patch may fall in the category of not deserving an answer at all
(to your standards).
The one thing I noticed is my mail client putting line-wrapping into the
patch, which should be easy to correct.
But before resending it, I would appreciate some feedback if something else
is 'obviously' wrong with it. To me it seems to be very difficult for the
issue at hand to fall into the category of being Obvious(ly) Correct.
Although the X11 and win32 concepts of extended line styles are very
similar, at least I did not know the scaling issues involved without trying
it out.
One thing which may be considered critical is my selection of the test
program. As noted it is Dia for win32 (ported by me [1]) through
gdk-win32-drawing code (PS_USERSTYLE usage implemented by me [2]).
So if I have misunderstood something there seven years ago, that two bugs
could compensate each other ;)
Another issue might be the unconditional implementation of PS_USERSTYLE.
After all it is only available with NT-based windows. Should x11drv check
for the version being emulated to also reproduce the failing behaviour? Or
would that be too much compatibility?
PS_USERSTYLE is available on all the systems I am currently using: 2000, XP
Vista.
What can I do to increase the probability of the patch being accepted?
Thanks,
Hans
[1] http://hans.breuer.org/dia/
[2] http://svn.gnome.org/viewvc/gtk%2B?view=revisionrevision=6330
[3] http://hans.breuer.org/dia/dia-wine.htm
Original-Nachricht
Betreff: implement PS_USERSTYLE handling, tested with Dia(win32)
Datum: Sun, 29 Mar 2009 19:45:05 +0200
Von: Hans Breuer h...@breuer.org
An: wine-patc...@winehq.org
From b89af7d06fc8cbf5210c61fd58ed62caeddad968 Mon Sep 17 00:00:00 2001
From: Hans Breuer h...@breuer.org
Date: Sun, 29 Mar 2009 18:27:29 +0200
Subject: implement PS_USERSTYLE handling, tested with Dia(win32) - see
http://hans.breuer.org/dia/dia-wine.htm
---
dlls/winex11.drv/pen.c | 31 +++
1 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/dlls/winex11.drv/pen.c b/dlls/winex11.drv/pen.c
index 49fe74c..039798e 100644
--- a/dlls/winex11.drv/pen.c
+++ b/dlls/winex11.drv/pen.c
@@ -54,12 +54,33 @@ HPEN CDECL X11DRV_SelectPen( X11DRV_PDEVICE *physDev,
HPEN hpen )
elp = HeapAlloc( GetProcessHeap(), 0, size );
GetObjectW( hpen, size, elp );
-/* FIXME: add support for user style pens */
logpen.lopnStyle = elp-elpPenStyle;
logpen.lopnWidth.x = elp-elpWidth;
logpen.lopnWidth.y = 0;
logpen.lopnColor = elp-elpColor;
-
+/* support for user style pens */
+if (MAX_DASHLEN elp-elpNumEntries)
+{
+FIXME(PS_USERSTYLE: len(dashes)MAX_DASHLEN %d,%d\n,
elp-elpNumEntries, MAX_DASHLEN);
+physDev-pen.dash_len = 0;
+}
+else
+{
+BOOL overflow = FALSE;
+physDev-pen.dash_len = elp-elpNumEntries;
+for (i = 0; i elp-elpNumEntries; ++i)
+{
+if (elp-elpStyleEntry[i] 255)
+{
+overflow = TRUE; /* can't fit the type */
+physDev-pen.dashes[i] = 255;
+}
+
Advice on where to place new private methods and access to private methods across modules.
Hi, I am working on creating a patch for X11DRV_AlphaBlend to allow Bitmap's with no DIBSECTION to work. The code to do this is fairly generic so I created a new method: DIB_CreateDIBSectionFromBitmap. I initially placed this in winex11.drv/dib.c, however the method required access to private methods in gdi32/dib.c. I then considered moving the method to gdi32, however again access to private methods seems to be an issue. I would prefer not to duplicate code across the dib.c files. Is there an accepted approach for acessing support methods across the modules? or should I just duplicate the necessary methods? Thanks Damian
X11DRV_AlphaBlend: FIXME not a DIB section
Hi, I'm trying to get an application running as best as possible under Wine and have found that X11DRV_AlphaBlend does not handle Bitmaps which are not a DIB Section. I have also found that a number of people have submitted some fixes to X11DRV_AlphaBlend: 1. http://www.nabble.com/(re-resend)-x11drv%3A-implement-X11DRV_AlphaBlend-for-non-dib-sources-td15501749.html#a15501749 2. http://archives.free.net.ph/message/20080602.110501.ba1ea794.el.html Is there a reason for these not being accepted? I have started doing my own patch but wish to ensure the maximium liklyhood of the patch being accepted. I am taking a slightly different approach of trying to convert the Bitmap into a DIB Section first, which would hopefully minimise any changes. Does any one have any advice on how to approach this fix? Thanks Damian
