http://bugs.winehq.org/show_bug.cgi?id=6955
--- Comment #31 from Henri Verbeet <hverbeet(a)gmail.com> 2009-12-15 08:19:27 ---
(In reply to comment #29)
> this might just be my ignorance, but aren't those "processes" being followed in
> the software rendering? I mean all one should need is a good understanding of
> OpenGL I should think.
Well, no. The patch attached to this bug only blends the vertices before
passing them to the hardware, it doesn't touch things like lighting or texcoord
generation. Implementing it in hardware means generating shaders to replace
fixed function vertex processing based on the various D3D device states, like
e.g. enabled lights, material settings, etc., and then adding vertex blending
support to that. The last part of adding vertex blending to those shaders is
about the same amount of work as the software implementation, but the first
part of building the infrastructure is a lot of work (although Stefan's
patchset already implements most of that).
--
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=6955
--- Comment #28 from Henri Verbeet <hverbeet(a)gmail.com> 2009-12-15 07:43:16 ---
(In reply to comment #27)
> I know this, how much trouble would it be to make a hardware implementation
> along side with this software rendering, and choose the hw one if supported
> by the users X / OpenGL / GPU ?
In principle not terribly hard, but it's a large amount of work. You'd need to
be pretty familiar with how fixed function vertex processing works in D3D, and
there's a relatively large risk of introducing regressions.
--
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=12135
Summary: Editplus syntax highlighting wrong at newline
Product: Wine
Version: CVS/GIT
Platform: Other
URL: http://www.editplus.com
OS/Version: other
Status: UNCONFIRMED
Keywords: download
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dank(a)kegel.com
To reproduce, install Editplus 3, edit a file hello.c,
and type the canonical hello world app:
#include <stdio.h>
int main(int argc, char **argv)
{
printf("Hello, world!\n");
return 0;
}
Note how the string constant is a different color.
Now move the cursor between Hello and World,
and hit the Enter key. The word world moves
to the next line and loses its color.
According to http://winehq.org/pipermail/wine-users/2008-March/030579.html
it should stay highlighted, and does on Windows.
Doing 'winetricks riched20' or 'winetricks riched30' doesn't help.
--
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=21016
Summary: regression - Dragon NaturallySpeaking installs much
more slowly than it used to
Product: Wine
Version: 1.1.34
Platform: PC
URL: http://nuance.com
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ole32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: susancragin(a)earthlink.net
This is a regression. I install dragon natspeak every day, and one day
installation speed slowed to a crawl.
This is the culprit.
The bug does not seem to affect other program functionality.
$ git bisect good
ee39a21d2b3f5e1a8d0f5519c316804ce16d9f45 is first bad commit
commit ee39a21d2b3f5e1a8d0f5519c316804ce16d9f45
Author: Vincent Povirk <vincent(a)codeweavers.com>
Date: Mon Nov 30 09:50:15 2009 -0600
ole32: Add DestroyDirEntry to the storage vtable.
:040000 040000 510c30a1cb42d209f763729317a56ac5a48ff68f
ec8e0d1f89bd2495e10ee67a15055cf0479e4bd7 M dlls
--
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=4742
--- Comment #16 from Detlef Riekenberg <wine.dev(a)web.de> 2009-12-14 15:42:38 ---
My initial tests where plain wrong.
I called LocalFree() on the Handle returned from the first EM_GETHANDLE
and then use the second handle for various API calls
(Since the same handle was returned in both EM_GETHANDLE calls,
a typical: use after free ....)
I try to rework the tests a bit this week.
--
By by ... Detlef
--
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.