http://bugs.winehq.com/show_bug.cgi?id=892
------- Additional Comments From marcus(a)jet.franken.de 2002-07-19 03:47 -------
If you want to use CPUID, use an exception handler around the
instruction which will trigger if it is not there.
Otherwise I do not see a problem to implement it for !Linux x86 systems.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=892>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=792
fgouget(a)codeweavers.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |download
------- Additional Comments From fgouget(a)codeweavers.com 2002-07-19 03:46 -------
You can get WinZip from the following URL:
http://www.winzip.com/ddchomea.htm
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=792>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=892
Summary: Implement GetSystemInfo using CPUID
Product: Wine
Version: CVS
Platform: PC
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: wine-ports
AssignedTo: wine-bugs(a)winehq.com
ReportedBy: fgouget(a)codeweavers.com
Currently GetSystemInfo reads the CPU information from /proc/cpuinfo. The
problem is that this only works on Linux and other x86-based platform only get
the defaults which are certainly not optimal for current CPUs.
One potential issue is that pre-586 (or is it pre-486) processors don't support
the CPUID instruction. But this it not a big issue and can probably be handled
in some way.
I have set this bug's platform to FreeBSD but this is just as valid for Solaris x86.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=892>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=455
------- Additional Comments From fgouget(a)codeweavers.com 2002-07-19 03:03 -------
Whoops, the keyword is 'FIXME' for this list of course.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=455>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=395
fgouget(a)codeweavers.com changed:
What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn|90, 93, 94, 95, 96, 98, 99, |
|100, 110, 324, 325, 326, |
|408, 409, 421, 422, 423, |
|424, 425, 475, 694, 695, |
|696, 697, 698, 780, 832, |
|833, 834, 836, 838, 845 |
Status|NEW |RESOLVED
Resolution| |INVALID
------- Additional Comments From fgouget(a)codeweavers.com 2002-07-19 02:52 -------
This meta-bug has been retired. The tasklist is now being kept track of by means
of the 'tasklist' keyword.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=395>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=455
fgouget(a)codeweavers.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
------- Additional Comments From fgouget(a)codeweavers.com 2002-07-19 02:52 -------
This meta-bug has been retired. The tasklist is now being kept track of by means
of the 'tasklist' keyword.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=455>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=885
------- Additional Comments From tony_lambregts(a)telusplanet.net 2002-07-19 02:50 -------
Created an attachment (id=235)
Horribly hacked solution that masks the problem (patch)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=885>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=885
------- Additional Comments From tony_lambregts(a)telusplanet.net 2002-07-18 23:30 -------
It's a timing problem, it seems that when the source and destination are the
same the screen is not updated properly before the next bitblt. I found this out
by putting a FIXME in a for loop. I wanted to slow this down so I could see the
problem as it progressed. What it did is clear the problem up.
....
physDevDst->exposures++;
wine_tsx11_unlock();
if (physDevDst == physDevSrc){
INT q;
for(q=1;q<1000 q++){
FIXME("Same Source;
}
}
return TRUE;
....
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=885>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=885
------- Additional Comments From dclark(a)akamail.com 2002-07-18 22:56 -------
Yep, it looks like that for me. I added a trace to check the parameters to
XCopyArea, and they look ok.
case SRCCOPY: /* 0xcc */
if (dcSrc->bitsPerPixel == dcDst->bitsPerPixel)
{
TRACE(" src_xy=%d,%d size=%d,%d dst_xy=%d,%d\n",
physDevSrc->org.x + visRectSrc.left,
physDevSrc->org.y + visRectSrc.top,
width, height,
physDevDst->org.x + visRectDst.left,
physDevDst->org.y + visRectDst.top );
I think what is happening is that the first bitblt is doing the scroll on an
internal image.
trace:bitblt:BitBlt hdcSrc=08dc 38,0 24 bpp->hdcDest=08dc 0,0 570x392x24 rop=cc0020
...
trace:bitblt:BITBLT_InternalStretchBlt src_xy=38,0 size=570,392 dst_xy=0,0
And then the second copies the entire image to the screen
trace:bitblt:StretchBlt 08dc 0,0 608x392x24 -> 0894 0,0 608x392x24 rop=cc0020
...
trace:bitmap:X11DRV_DIB_SetImageBits
XPutImage(44041069,0x8079818,0x80b3ec0,0,0,0,0,608,436)
...
trace:bitblt:BITBLT_InternalStretchBlt src_xy=0,0 size=608,392 dst_xy=16,22
The dst_xy on this second one is offset to accomodate the frame (I think).
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=885>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.