https://bugs.winehq.org/show_bug.cgi?id=37859
Bug ID: 37859
Summary: BOINC 6.x/7.x take a long time to "start" when
launched from boincmgr
Product: Wine
Version: 1.7.33
Hardware: x86-64
URL: http://boinc.berkeley.edu/dl/boinc_7.4.36_windows_inte
lx86.exe
OS: Linux
Status: NEW
Keywords: download, performance, source
Severity: trivial
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: imwellcushtymelike(a)gmail.com
Distribution: Ubuntu
Created attachment 50421
--> https://bugs.winehq.org/attachment.cgi?id=50421
Wine 1.7.33 / BOINC 7 console output
There are a number of ways to start BOINC on a system:
1. At system startup (daemon/service).
2. On its own (in a console).
3. By launching boincmgr.exe (BOINC Manager).
As of BOINC 6.x, option 3 can take around 60 seconds to "start".
In reality the BOINC client (boinc.exe) starts immediately, just as quickly as
any other way, but boincmgr.exe struggles repeatedly to connect.
However:
A. If BOINC is already running, boincmgr.exe connects instantly.
B. If a second boincmgr.exe is launched immediately after the first (giving the
few seconds for boinc.exe to start) it can connect immediately.
C. boincmgr.exe can connect to any other client without any issue.
So it's *just* when boincmgr.exe first launches boinc.exe that seems to confuse
things.
>From stdoutgui.txt:
[01/06/15 16:24:00] TRACE [9]: init_asynch() boinc_socket: 212
[01/06/15 16:24:00] TRACE [9]: init_asynch() connect: -1
[01/06/15 16:24:03] TRACE [9]: init_poll(): sock = 212
[01/06/15 16:24:04] TRACE [9]: init_poll(): sock = 212
[01/06/15 16:24:04] TRACE [9]: init_poll(): sock = 212
[...]
[01/06/15 16:25:01] TRACE [9]: init_poll(): sock = 212
[01/06/15 16:25:01] TRACE [9]: asynch init timed out
[01/06/15 16:25:01] TRACE [9]: init_asynch() boinc_socket: 212
[01/06/15 16:25:01] TRACE [9]: init_asynch() connect: -1
[01/06/15 16:25:01] TRACE [9]: init_poll(): sock = 212
[01/06/15 16:25:01] TRACE [9]: init_poll(): connected
So it times out after 60 seconds and tries again with success.
In comparison, scenario A gives:
[01/06/15 16:41:13] TRACE [42]: init_asynch() boinc_socket: 216
[01/06/15 16:41:13] TRACE [42]: init_asynch() connect: -1
[01/06/15 16:41:14] TRACE [42]: init_poll(): sock = 216
[01/06/15 16:41:14] TRACE [42]: init_poll(): connected
Tried both 32- and 64-bit binaries in both 32- and 64-bit WINEPREFIXes, same
result each time.
BOINC 5.8.16 does not have this problem.
$ sha1sum boinc*.exe
b4cdb23c8f51f33799c9d784ba38a9f69338fb68 boinc_5.8.16_windows_intelx86.exe
c8dba7a184076240cdeef5032a9825a90244bb3f boinc_6.6.38_windows_intelx86.exe
a67223afefb7072c82b366cab9d21e21ad2a719d boinc_7.0.64_windows_intelx86.exe
93f7a6639eca9bd7c8558146c2b23f954dffe9ef boinc_7.0.64_windows_x86_64.exe
c86c17637d59ea12e78ed3fb56bb92beae897132 boinc_7.2.33_windows_intelx86.exe
d761a1a57cf7836e2a33a5cd68ddb3bdd5e57af6 boinc_7.2.33_windows_x86_64.exe
277f9cf8007fe5f6901f6c04a4d3aa985fd172a9 boinc_7.2.42_windows_intelx86.exe
d1f4f5de1ccef0977009800a9ff70321859b45b2 boinc_7.2.42_windows_x86_64.exe
2919cc9b6163019fc014a7fa4190bee8ead4b544 boinc_7.4.36_windows_intelx86.exe
c2334aa9696f11a3f50dac07d1648c6b77ef9ae2 boinc_7.4.36_windows_x86_64.exe
--
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=35655
Bug ID: 35655
Summary: Wined3d performance drop
Product: Wine
Version: 1.7.13
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: wylda(a)volny.cz
In between 1.7.13 and wine-1.7.13-27-ge610713 i noticed performace drop in
3Dmark 2000.
In overall score it makes -14%, but as the CPU tests and MTexels/s &
KTriangels/s remained cca the same, some FPS tests dropped to -20% ("8MB
Texture Rendering Speed").
Since 1.7.13 there were not too much 3d changes, but anyway i bisected to:
4c4552c5a1910a9d5adf8eccff0ac62d89ffe376 is the first bad commit
commit 4c4552c5a1910a9d5adf8eccff0ac62d89ffe376
Author: Ken Thomases <ken(a)codeweavers.com>
Date: Wed Feb 19 16:14:53 2014 -0600
wined3d: Restore the pixel format of the window whose pixel format was
actually changed.
--
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=35418
Bug ID: 35418
Summary: some drawing operations in Mixcraft 6 are very slow
with client-side graphics enabled
Product: Wine
Version: 1.7.11
Hardware: x86
URL: http://acoustica.com/mixcraft/download.htm
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winex11.drv
Assignee: wine-bugs(a)winehq.org
Reporter: s_chriscollins(a)hotmail.com
Classification: Unclassified
Regression SHA1: 33ac850c80634c891b0c157bbffa612f70954a40
According to my git bisect, this bug appeared after the following commit:
--------
winex11: Use window surfaces for rendering top-level windows.
It can be disabled by setting "ClientSideGraphics"="n".
commit: 33ac850c80634c891b0c157bbffa612f70954a40
--------
After the above commit, the following operations in Mixcraft 6 are very
slow/laggy:
1) Scrolling vertically in the track view when there are lots of tracks present
2) Scrolling horizontally in piano roll view.
3) Resizing the workspace between the top and bottom view.
4) Adjusting the knobs and sliders of certain FX plugins.
Steps to Reproduce:
1) Download and setup the Mixcraft trial
(http://acoustica.com/mixcraft/download.htm).
2) If you are opening Mixcraft for the first time, it will auto-load and play a
demo project. After this happens, click the "Open Project" icon (looks like a
folder), and open "Callisteia.mx6". If it isn't showing in the file picker by
default, you can find it in: "C:\Program Files\Acoustica Mixcraft 6\Example
Projects". Go to step 4.
3) If you are opening Mixcraft after having already opened it before, it will
start instead with a "New Project" dialog. Simply click the "Browse..." button
here to find and open the file mentioned in step 2.
4) With "Callisteia.mx6" now opened, use the scrollbar to the right to scroll
up and down through all the tracks in the project.
5) Double-click on the instrument clip for track #8 (Sweet Flute). This will
bring up the clip in notation view at the bottom half of the screen. Near the
bottom-left, change Editor Type from "Notation" to "Piano Roll". Use the
scrollbar to scroll right and left in the piano roll view.
6) Position your cursor just below the playback controls near the middle of the
screen; it should turn into a resize handle. Hold down the mouse button and
move the mouse up and down to resize the split between the top and bottom
screen areas.
Result: The tests done in steps 4-6 are responsive and reasonably smooth in
Wine versions prior to the aforementioned commit. In versions after the commit,
these tests give very choppy and laggy results.
I had mentioned that some FX plugins were also choppy/laggy, but this only
affects some of the plugins that are bundled with Mixcraft Pro Studio 6, which
is not available as a free trial download. Just in case anybody wants to know,
the plugins are: FAT+, Ferox Tape Emulator, all "Mid-Side" plugins, TB Gate,
and TimeMachine. If you want to test a free plugin that exhibits the slowness,
and you know how to bring up a VST's GUI within Mixcraft, you can download
L3V3LL3R: http://www.platinumears.com/l3v3ll3r.html. Be sure to copy the .dll
file to "C:\Program Files\VST".
--
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=6176
Alexandre Julliard <julliard(a)winehq.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
--- Comment #13 from Alexandre Julliard <julliard(a)winehq.org> ---
Closing bugs fixed in 1.8-rc2.
--
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=39039
Bug ID: 39039
Summary: Popup tooltips missing and buttons don't work on
mageia.org/en/downloads/
Product: Wine
Version: 1.5.1
Hardware: x86
OS: Linux
Status: NEW
Keywords: download, regression, source
Severity: normal
Priority: P2
Component: mshtml
Assignee: wine-bugs(a)winehq.org
Reporter: gyebro69(a)gmail.com
CC: jacek(a)codeweavers.com
Regression SHA1: 6c6744f80066f0aa46939a2d4c0af9c34f932e8b
Distribution: ---
Created attachment 52001
--> https://bugs.winehq.org/attachment.cgi?id=52001
terminal output
If you visit the download page for Mageia Linux distribution
wine iexplore https://www.mageia.org/en/downloads/
you can see 3 big buttons at the bottom of the page titled 'Classic', 'Live'
'Network installation'. Place the mouse pointer over the buttons >> nothing
happens. Normally, a popup tooltip should appear giving you a short description
of the selected installation flavour.
Click on one of those buttons >> nothing happens, again. Normally another
button should appear below, allowing you to choose PC architecture and download
method.
Popup tooltips as well as those buttons used work until
commit 6c6744f80066f0aa46939a2d4c0af9c34f932e8b
Author: Jacek Caban <jacek(a)codeweavers.com>
Date: Tue Mar 27 13:40:01 2012 +0200
mshtml: Use jscript.dll for JavaScript for all zones except untrusted.
Reverting the patch on current git fixes the problem.
Firefox when installed in Wine also can handle those buttons properly.
In the terminal I'm getting these fixmes when clicking on a button on the
download page:
fixme:mshtml:HTMLEventObj_get_toElement (0xbdde08)->(0x33dc10)
fixme:mshtml:HTMLEventObj_get_offsetY (0xbdde08)->(0x33dc10)
fixme:mshtml:HTMLEventObj_get_offsetX (0xbdde08)->(0x33dc10)
fixme:mshtml:HTMLEventObj_get_fromElement (0xbdde08)->(0x33dc10)
fixme:mshtml:HTMLEventObj_get_fromElement (0xbdde08)->(0x33d7e0)
Tested with wine-1.7.48-100-ge3c6777 + Wine Gecko 2.36 installed
--
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=9435
Summary: MDI child window outside main window gives scrollbars
Product: Wine
Version: CVS/GIT
Platform: Other
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-user
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: peter(a)cendio.se
In Wine, if you move a MDI child window outside the borders of the main window,
you'll get scrollbars. This does not happen in Windows. This causes problems
with some applications which creates MDI child windows that occupies the entire
main window area. In this case, scroll windows appears, which obscures parts of
the MDI child. Tested with Wine as of 2007-08-23, using
http://www.cendio.se/~astrand/wine/11-mdi-scrollbar/mdi1.exe.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=3952
Anastasius Focht <focht(a)gmx.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |clawild(a)hotmail.com
--- Comment #74 from Anastasius Focht <focht(a)gmx.net> ---
*** Bug 39037 has been marked as a duplicate of this bug. ***
--
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=39684
Bug ID: 39684
Summary: e-Deklaracje: Crash while opening an form
Product: Wine
Version: 1.7.55
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: lukasz.wojnilowicz(a)gmail.com
Distribution: ---
Created attachment 52908
--> https://bugs.winehq.org/attachment.cgi?id=52908
Opening requested form
Steps to reproduce:
1) remove ~/.wine
2) winetricks adobeair mspatcha
3) install Adobe Reader 10.1 PL
4) turn off protected mode by
wine reg add "HKLM\\SOFTWARE\\Policies\\Adobe\\Acrobat
Reader\\10.0\\FeatureLockDown" /v bProtectedMode /t REG_DWORD /d 0 /f
5) install e-DeklaracjeDesktop.air
6) start e-Deklaracje.exe
7) give your name
8) choose forms catalog (see 8. in attachment)
9) choose one of the forms (see 9. in attachment)
10) press open (see 10. in attachment)
Behaviour:
Separate window opens with circular progress bar and then Wine error window
shows up.
Expected behaviour:
Requested form should appear in separate window ready to fill in.
Additional info:
1) Adobe Reader
https://ardownload2.adobe.com/pub/adobe/reader/win/10.x/10.1.0/pl_PL/AdbeRd…
2) WINETRICKS_VERSION=20151110
--
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=8051
--- Comment #129 from swswine(a)gmail.com ---
(In reply to Stefan Dösinger from comment #128)
> Does it use a shader too, or just a vertex declaration?
Both shader and vertex declaration.
> It's probably easier to hook into
> https://www.opengl.org/wiki/Transform_Feedback instead.
Yes, sure, I see.
--
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=8051
--- Comment #128 from Stefan Dösinger <stefan(a)codeweavers.com> ---
(In reply to swswine from comment #127)
> At the first place ProcessVertecies does not understand VertexDeclaration
> output buffer specification, while sims2 wants to use them and output buffer
> has zero FVF code.
Does it use a shader too, or just a vertex declaration?
> I know it may sound very weird, but can't shader support in ProcessVertices
> be done in a shorter way by just using application shader function in fixed
> function GLSL pipeline in a way similar to how the normal application
> shaders (without ProcessVertices) are used?
It's possible, but has its own set of issues. E.g. what do you do if the game
calls ProcessVertices two times with two different shaders (shader constants)
and the same output buffer, and then draws the entire buffer with one draw
call? What happens if one of the input buffers goes away or is modified between
ProcessVertices and DrawPrimitive? The shader state, and in particular vertex
shader constants and potential vertex textures, is pretty huge. Managing this
gets complex fast...
It's probably easier to hook into
https://www.opengl.org/wiki/Transform_Feedback instead.
--
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.