http://bugs.winehq.org/show_bug.cgi?id=30627
Bug #: 30627
Summary: Appending text to a large richedit is very slow
Product: Wine
Version: 1.5.3
Platform: x86
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: richedit
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dank(a)kegel.com
Classification: Unclassified
Although the pathological case reported in bug 30614 is now fixed,
all is not yet well.
When repeatedly appending lines, builtin riched20 starts out about 3x slower
than native, and at 40k lines, is about 10x slower than native.
This is painful for long-running apps that use richedit for verbose logs.
(Measured with the attached program and today's git on my i5,
appending 1000 lines to an empty richedit control takes
builtin hidden: 907 ms
builtin visible: 4862 ms
native hidden: 368 ms
native visible: 4530 ms
Appending 1000 lines to a richedit control which already contains 40000 lines
takes:
builtin hidden: 22169 ms
builtin visible: 33002 ms
native hidden: 1750 ms
native visible: 4807 ms )
Building wine's riched20 with -O1 -fno-inline and profiling with 'perf' shows
62.60% ME_WrapMarkedParagraphs
12.07% ME_PaintContent
9.99% ME_InvalidateMarkedParagraph
at 50k lines.
Initial inspection seems to show that most of the time in
ME_WrapMarkedParagraphs is in the function itself, not in any
called functions.
Adding trace statements to all callers of ME_WrapMarkedParagraphs, I see
one call during EM_EXSETSEL:
ME_Repaint Calling ME_WrapMarkedParagraphs
and four calls during EM_REPLACESEL:
ME_UpdateRepaint Calling ME_WrapMarkedParagraphs
ME_UpdateScrollBar Calling ME_WrapMarkedParagraphs
ME_Repaint Calling ME_WrapMarkedParagraphs
ME_UpdateScrollBar Calling ME_WrapMarkedParagraphs
This is the case whether the window is hidden or not.
Bug 13355 (which Dylan says is separate, since it's about richedit
being slow on a single large call to WM_SETTEXT) suggests in comment 14
ways to remove some redundant calls to ME_WrapMarkedParagraphs,
and to let one of them return early.
In addition to those ideas, for this bug, it would be useful if
ME_WrapMarkedParagraphs (and ME_InvalidateMarkedParagraph) could
avoid making a linear scan across all paragraphs.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39773
Bug ID: 39773
Summary: File->Open slowdown caused by desktop.ini checks
Product: Wine
Version: 1.8-rc2
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: shell32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
To reproduce this you will need two Linux machines, a Samba server and a Samba
client.
On the Samba server:
* Create a directory with lots of subdirectories and files:
mkdir smbdir
cd smbdir
for i in `seq 1 200`;do mkdir sub$i; done
for i in `seq 1 200`;do touch file$i; done
* Export smbdir through Samba. (alternatively you could export '/' and use
'/usr/lib' as a replacement for smbdir)
On the Samba client:
* Mount the Samba share. You can either do it by adding a /etc/fstab line like:
//MYSERVER/smbdir /mnt/smbdir cifs
rw,username=MYLOGIN,password=MYPASSWORD,domain=MYDOMAIN 0 0
Or by starting Nautilus in GNOME, clicking on '+Other Places' -> Windows
network... using GVFS. Note that in this case you'll have to work around the
colon in the mount point filename (see bug 34868).
* Slow down the network connection using a command like this:
tc qdisc add dev eth0 root netem delay 10ms
* Check the above line is effective by running:
ping MYSERVER
The rtt should be around 10ms.
* cd /mnt/root/
wine notepad
* Open the File->Open dialog, navigate to the smbdir folder exported through
Samba.
* BUG: The initial display will be slow and scrolling through the many
subfolders will be very slow.
* Change the file mask to '*.*'.
* Scroll all the way to the right so only files are visible. As long as only
files are visible scrolling should then be very fast!
* Finally change the rtt to 0ms on the Samba server and check that the RTT is
under 1ms.
* Now test again notepad's File->Open dialog and everything should be
reasonably fast.
The problem is that whenever File->Open displays a folder in the open file
dialog it checks whether it contains a desktop.ini file to display the right
icon. That's not cached, thus incurring a few file lookups per folder
displayed. For local file systems that's fast enough but on network shares with
a non-trivial RTT the speed impact is significant. A 10+ ms RTT makes the
dialog essentially unusable.
Note that when displaying a filename we have everything in the cache so
redisplays are lightning fast and track the mouse.
Also Microsoft Office has the same problem even though it does not use the
standard comdlg32 dialog (though that may depend on the Windows version being
emulate). On Windows Microsoft Office suffers no slowdown in this situation.
What this means is that the standard common dialog is probably the wrong level
for fixing this.
Hacking SHELL32_GetCustomFolderAttributeFromPath() in shell32 to just return
FALSE speeds things up greatly. The display still lags a bit behind the mouse
so that there may be some residual file lookups or other slowdowns but it's
still night and day.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41234
Bug ID: 41234
Summary: FreeGate 7.59 does not run on the latest versions of
some distros
Product: Wine
Version: 1.9.12
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: caminostro3(a)gmail.com
Distribution: Fedora
Created attachment 55521
--> https://bugs.winehq.org/attachment.cgi?id=55521
Terminal output of wine running freegate 7.59
I tried running Freegate 7.59 (Latest version) on Fedora 23, Linux Mint 17, and
Ubuntu 16.04. The first dialogs asking for EULA agreement and some options
appear, but the main window does not. The terminal output of running this
application with wine 1.9.12 on Fedora 23 is attached.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45383
Bug ID: 45383
Summary: Xanadu Next: movies not working (avi/MPEG-4 (XviD))
Product: Wine
Version: 3.11
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: quartz
Assignee: wine-bugs(a)winehq.org
Reporter: betaversiondot(a)gmail.com
Distribution: Debian
Created attachment 61699
--> https://bugs.winehq.org/attachment.cgi?id=61699
Xanadu Next wine-3.11
Black screen instead of movies.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46216
Bug ID: 46216
Summary: Lords of the Fallen needs
ThreadEnableAlignmentFaultFixup
Product: Wine
Version: 3.21
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: andrey.goosev(a)gmail.com
Distribution: ---
Spamming output after launching:
fixme:thread:NtSetInformationThread info class 7 not supported yet
wine-3.21-114-g1582ae6b04
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26541
Summary: Dragon Saga doesn't start
Product: Wine
Version: 1.3.16
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dank(a)kegel.com
Installing DragonSagaInstaller-0.1.29-20110216.msi
went fine, but
$ cd ~/.wine/drive_c/Program Files/Gravity/Dragon Saga
$ wine Release/DragonSaga.EXE
fails like this:
fixme:ntdll:NtQueryInformationProcess (process=0xffffffff) Unimplemented
information class: ProcessDebugFlags
Unhandled exception: privileged instruction in 32-bit code (0x0123980c).
Backtrace:
=>0 0x0123980c in dragonsaga (+0xe4980c) (0x0032fea0)
1 0x7edaa2fc call_process_entry+0xb() in kernel32 (0x0032feb8)
2 0x7edac593 start_process+0x52(peb=0x1) [dlls/kernel32/process.c:1086] in
kernel32
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28089
Summary: exception handling code touches stack for exceptions
handled by the debugger
Product: Wine
Version: unspecified
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: bernhardloos(a)googlemail.com
Created an attachment (id=35971)
--> (http://bugs.winehq.org/attachment.cgi?id=35971)
a hack to work around the problem
Wine places the CONTEXT and EXCEPTION_RECORD structures onto the stack past ESP
during the unix signal handler and continues with most of the exception
handling code outside of the signal handler. Unfortunately and contrary to
windows behavior the debugger gets notified only after this happens. Windows
doesn't touch the stack at all, if the exception is handled by the debugger.
This makes it very hard to single step trough code which keeps useful data past
ESP (securom 8 for example).
it's easy to show with this small test:
void foo()
{
char *x = 0, *y = 0, *from = 0, *to = 0;
char c;
x = &c;
y = &c - 500;
while (y != x)
*y++ = 0x55;
c = 0x77; /* single step a few times here */
y = &c - 500;
while (y != x)
{
if (*y != 0x55)
if (from)
to = y;
else
from = y;
y++;
}
/* to and from shoudl be NULL */
}
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43567
Bug ID: 43567
Summary: Vietcong - game crashes during radiocalls
Product: Wine
Version: 2.14
Hardware: x86-64
URL: http://www.moddb.com/games/vietcong/downloads/vietcong
-singleplayer-demo
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: havran.jan(a)email.cz
Distribution: ArchLinux
Created attachment 58977
--> https://bugs.winehq.org/attachment.cgi?id=58977
Vietcong - terminal log
Vietcong crashes when radiocall icon is shown. This bug is also reproduciable
on Windows > Vista, but it works on Windows XP. There exists community tool:
VCStarter, which fixes this for newer Windows and also for Wine. I have spoke
with VCStarter creator and he told me that the game uses some dirty assembler
in that part (maybe part of anticheat protection or no-cd crack?). I have
doubts if it is really Wine bug, but since this game works on Windows <= XP, it
should also work on Wine (with Win XP compatibility).
PS: You will not be able tu run this game probably because of bug #9337. As a
workaround, you can use VCStarter (version 1.7 only, older versions did not fix
the bug) or patch from bug #39057 - all this is described in bug #9337
PPS: While patch from bug #39057 fixes bug #9337 crashing for all Vietcong
versions, VCStarter works only with Vietcong 1.60 (so it does not work with
Vietcong demo version).
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33310
Bug #: 33310
Summary: Minimizing window erases chess board in Shredder
Classic 4 Windows
Product: Wine
Version: unspecified
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: clavius(a)live.com
Classification: Unclassified
Minimizing the program window causes the play area to come up blank upon
re-maximization in Shredder Classic 4 Windows chess.
To duplicate the bug:
1) Obtain Shredder Classic 4 Windows demo from
http://download.shredderchess.com/pc/sc4/prg/myscl/SetupShredderClassic4.exe
2) Install the program under Wine. I've tested this with Wine versions 1.4 and
several 1.5 releases under both Ubuntu and openSUSE Linux, 64-bit OS.
3) Start the program either by command-line or clicking the icon. You'll see
the normal Shredder game screen. Start a new game to get a chess board.
4) Minimize the Shredder window.
5) Now maximize the window again, and the game play area (chess board and all)
will have disappeared. This happens with any combination of layouts and chess
sets I've tried (most if not all, including the 3d ones).
This screen re-draw issue seems to be the only one I haven't been able to
resolve by downloading winetricks and various Microsoft runtime libraries.
Shredder for Windows offers a few features unavaiable in the native Linux
version, including the ability to play Chess960. It also has, in my opinion, a
nicer looking GUI. Would be nice to play under Wine.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18508
Summary: Sony Acid Pro 7 Fails to Install
Product: Wine
Version: unspecified
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: aliendude5300(a)gmail.com
Created an attachment (id=21153)
--> (http://bugs.winehq.org/attachment.cgi?id=21153)
What debug messages appeared during installation of Sony Acid Pro 7 on default
Wine installation.
The installer for Sony Acid Pro 7 fails to install the necessary files and
exits in Wine 1.1.21.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.