Re: [PATCH 1/2] wined3d: Set GL_NONE for glReadBuffer / glDrawBuffer on FBO initialization.
On 25 April 2013 23:55, Matteo Bruni wrote: > 2013/4/25 Henri Verbeet : >> Seems ok, though a small comment explaining the issue this patch fixes >> probably wouldn't hurt. > > A comment in the commit message or in the code? > The code. For example above the "glReadBuffer(GL_NONE);".
Re: [PATCH 1/2] gdi32: Clip font glyphs to fit within text metrics. (try 2)
On 04/25/2013 12:28 PM, Alexandre Julliard wrote: It doesn't work here: ../../../../wine/tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so ../../../../wine/dlls/comctl32/tests/listview.c && touch listview.ok wine: Unhandled page fault on write access to 0x400053b34 at address 0x2b4c3d69e6b7 (thread 0398), starting debugger... winedbg: Internal crash at 0x2b53f78066b7 make: *** [listview.ok] Error 84 Thanks for the heads-up, AJ. I can't reproduce this problem, and it's strange that the debugger itself suffered an internal crash as well. Can anyone else verify? Did something mess up during AJ's build? Thanks for the help, Sam
Re: [PATCH 2/2]vbscript: Implemented builtin function CBool(try 3)
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=25302 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP2 (32 bit) === No test summary line found === WXPX64 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAX64 (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === WXPX64 (64 bit) === No test summary line found === WVISTAX64 (64 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found
Re: [PATCH 1/2]vbscript: Implemented builtin function CInt(try 3)
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=25301 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP2 (32 bit) === No test summary line found === WXPX64 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAX64 (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === WXPX64 (64 bit) === No test summary line found === WVISTAX64 (64 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found
Re: [PATCH 1/2] wined3d: Set GL_NONE for glReadBuffer / glDrawBuffer on FBO initialization.
2013/4/25 Henri Verbeet : > Seems ok, though a small comment explaining the issue this patch fixes > probably wouldn't hurt. A comment in the commit message or in the code? > On 25 April 2013 20:43, Matteo Bruni wrote: >> +if (target == GL_READ_FRAMEBUFFER) >> +context_bind_fbo(context, GL_DRAW_FRAMEBUFFER, draw_binding ? >> &draw_binding : 0); >> +else >> +context_bind_fbo(context, GL_READ_FRAMEBUFFER, read_binding ? >> &read_binding : 0); >> > I don't think using 0 here is strictly wrong, but a proper NULL would > probably be clearer. Indeed :/ > As a followup, I think we can actually get rid of > the glGenFramebuffers() in context_bind_fbo() these days and just pass > a GLuint instead of a pointer. The only place left that actually > creates FBOs should be context_apply_fbo_entry(). Good idea. I'll explore that. Thanks for the review, as usual.
Re: [PATCH 1/2] wined3d: Set GL_NONE for glReadBuffer / glDrawBuffer on FBO initialization.
Seems ok, though a small comment explaining the issue this patch fixes probably wouldn't hurt. On 25 April 2013 20:43, Matteo Bruni wrote: > +if (target == GL_READ_FRAMEBUFFER) > +context_bind_fbo(context, GL_DRAW_FRAMEBUFFER, draw_binding ? > &draw_binding : 0); > +else > +context_bind_fbo(context, GL_READ_FRAMEBUFFER, read_binding ? > &read_binding : 0); > I don't think using 0 here is strictly wrong, but a proper NULL would probably be clearer. As a followup, I think we can actually get rid of the glGenFramebuffers() in context_bind_fbo() these days and just pass a GLuint instead of a pointer. The only place left that actually creates FBOs should be context_apply_fbo_entry().
Re: [PATCH 1/2] gdi32: Clip font glyphs to fit within text metrics. (try 2)
Sam Edwards writes: > From a2905abf287ff1ac44c93119d76b14b6fc3992c3 Mon Sep 17 00:00:00 2001 > From: Sam Edwards > Date: Sat, 20 Apr 2013 05:48:07 -0600 > Subject: gdi32: Clip font glyphs to fit within text metrics. It doesn't work here: ../../../../wine/tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so ../../../../wine/dlls/comctl32/tests/listview.c && touch listview.ok wine: Unhandled page fault on write access to 0x400053b34 at address 0x2b4c3d69e6b7 (thread 0398), starting debugger... winedbg: Internal crash at 0x2b53f78066b7 make: *** [listview.ok] Error 84 -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 1/7] wined3d: Add a new structure for for d3d limits and other info
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please ignore this patch. I figured that my series might collide with Henri's, so I canceled the send process. And indeed there are conflicts, so I'll resend my patches rebased on top of Henri's. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJReSS/AAoJEN0/YqbEcdMwElkP/AiDEqVSaMxTW+sOaQava97g a0cOBpHTU+lInUuUXIS2WVe65D+IhkdYJHnMIrSUVdquvT1x+pLVgr+2J4jczFX7 /9Ay0gAjMVbKsKIYO4tvOQgSru/RdAljTg6uaIw+qTDrHZvQLW/sJu3JcbAp0GW7 9pGEzPvRr6hNsOyXE+DQlTEsT3vkbEUTRr01j4+znF50laYV2s3e5saZHyXULyY8 ObEf3n2ppQgcO4keQg7wAPLydw+xiNcYOw9724fh/xyezj8MXoT1CDHeio7yPfhg xp76kNWzNERQcWaDT7QXwuWLRXy5H3VodWm4PEMXvqXyxkJJycm2jECvTOTjrrke iswKGqh9n0gTWQjse2eUY/fKxpjhh/ySxDcJq093swHHbvrCngL8Q5dYu/Ch3cFu JbLu4pHla3iAmJKftVTT/iRq6vwsLB7tzloCoA7e8T+GFmsA39RPFI6zttCIoA60 kui5a4Ofd6/sGMFaqg2VBK+2crGJzVzN6VRvglg63A0hNr0UGbkFC/6iQK8FzxyA A+uPGr5Xrd/vGpKZksMMH68JiK5kYXm+fsiVI1F1rcAcfdh6STQBoThcig1N/HXu fA8daluv4+PgQ9RhgzlioBsVFGxkZ1FbM8XjKlcnKQb0ZK3DXLHLEzspvmBnr3Pi MK94F9BvqMDa6Wi57sgT =Wh/i -END PGP SIGNATURE-
RE: [0/4] Improve wineconsole and kernel32
>>The first and second patches should be applied to source before compiling >>Wine. If this is not done, the compiler will exit with errors. (The first is >>a patch for server/protocol.def and requires tools/make_requests to be run). >After each patch, Wine should be able to compile correctly (e.g. for >regression testing) >If not, you should split your patches differently IMO. >Frédéric Yes, I know. I thought that rule didn't apply when dealing with patches to server/protocol.def. I'll combine the first and second patches together and resubmit. Hugh
Wine Gecko 2.21-beta1
Hi all,
As some of you might have noticed, the final Wine Gecko 2.20 was never
been released, although it was scheduled for about three weeks ago. This
is mostly due to my lack of time, combined with the fact that part of
that time I was busy with some Gecko work that would be nice to have in
Wine. Being 3 weeks late means that we also have 3 weeks until the next
Firefox release, so we may just wait a bit longer and do another release
based on newer upstream code base. This way I may use the new beta to
include some of the changes that I did lately, which would be too risky
to go straight to release. Those new improvements contain, among others,
a fix for Adobe CS4 products installers.
In this beta, the testing is easier than ever. Our auto installer knows
about the beta which, combined with the fact that we cache downloaded
packages now, means that the attached Wine patch is all you need to
comfortably test the new package. Just apply the patch you the Wine tree
and everything should work. All tests are appreciated.
Thanks,
Jacek
diff --git a/dlls/appwiz.cpl/addons.c b/dlls/appwiz.cpl/addons.c
index 2a47b84..a3bfd0b 100644
--- a/dlls/appwiz.cpl/addons.c
+++ b/dlls/appwiz.cpl/addons.c
@@ -53,14 +53,14 @@
WINE_DEFAULT_DEBUG_CHANNEL(appwizcpl);
-#define GECKO_VERSION "1.9"
+#define GECKO_VERSION "2.21-beta1"
#ifdef __i386__
#define ARCH_STRING "x86"
-#define GECKO_SHA "d2553224848a926eacfa8685662ff1d7e8be2428"
+#define GECKO_SHA "246672bf7b5c6fb896865f2e2abadf5e16bdcaea"
#elif defined(__x86_64__)
#define ARCH_STRING "x86_64"
-#define GECKO_SHA "c7cd0994f89dd15b36ce8dacaa33d0ec47c407d1"
+#define GECKO_SHA "389aea6f0bc3db77ad1ed0645ea3a4885a5df04f"
#else
#define ARCH_STRING ""
#define GECKO_SHA "???"
diff --git a/dlls/mshtml/htmlelem2.c b/dlls/mshtml/htmlelem2.c
index 24aaba5..516a3f5 100644
--- a/dlls/mshtml/htmlelem2.c
+++ b/dlls/mshtml/htmlelem2.c
@@ -1253,22 +1253,22 @@ static HRESULT WINAPI
HTMLElement2_getElementsByTagName(IHTMLElement2 *iface, BS
IHTMLElementCollection
**pelColl)
{
HTMLElement *This = impl_from_IHTMLElement2(iface);
-nsIDOMNodeList *nslist;
+nsIDOMHTMLCollection *nscol;
nsAString tag_str;
nsresult nsres;
TRACE("(%p)->(%s %p)\n", This, debugstr_w(v), pelColl);
nsAString_InitDepend(&tag_str, v);
-nsres = nsIDOMHTMLElement_GetElementsByTagName(This->nselem, &tag_str,
&nslist);
+nsres = nsIDOMHTMLElement_GetElementsByTagName(This->nselem, &tag_str,
&nscol);
nsAString_Finish(&tag_str);
if(NS_FAILED(nsres)) {
ERR("GetElementByTagName failed: %08x\n", nsres);
return E_FAIL;
}
-*pelColl = create_collection_from_nodelist(This->node.doc, nslist);
-nsIDOMNodeList_Release(nslist);
+*pelColl = create_collection_from_htmlcol(This->node.doc, nscol);
+nsIDOMHTMLCollection_Release(nscol);
return S_OK;
}
diff --git a/dlls/mshtml/nsiface.idl b/dlls/mshtml/nsiface.idl
index 368a154..18653e6 100644
--- a/dlls/mshtml/nsiface.idl
+++ b/dlls/mshtml/nsiface.idl
@@ -23,7 +23,7 @@
* compatible with XPCOM, usable in C code.
*/
-cpp_quote("#define GECKO_VERSION \"1.9\"")
+cpp_quote("#define GECKO_VERSION \"2.21-beta1\"")
cpp_quote("#define GECKO_VERSION_STRING \"Wine Gecko \" GECKO_VERSION")
import "wtypes.idl";
@@ -179,10 +179,7 @@ typedef nsISupports nsIDOMHistory;
typedef nsISupports nsIDOMNavigator;
typedef nsISupports nsIDOMMediaQueryList;
typedef nsISupports nsIDOMScreen;
-typedef nsISupports nsIDOMCrypto;
-typedef nsISupports nsIDOMPkcs11;
typedef nsISupports nsIAnimationFrameListener;
-typedef nsISupports nsIDOMMozURLProperty;
typedef nsISupports nsIDOMStorageList;
typedef nsISupports nsILocalFile;
typedef nsISupports nsIDOMHTMLMenuElement;
@@ -195,6 +192,10 @@ typedef nsISupports nsIDOMBlob;
typedef nsISupports nsIPrivacyTransitionObserver;
typedef nsISupports nsIDOMHTMLPropertiesCollection;
typedef nsISupports mozIDOMApplication;
+typedef nsISupports nsILoadGroupConnectionInfo;
+typedef nsISupports nsIDOMCrypto;
+typedef nsISupports nsIDOMPkcs11;
+typedef nsISupports nsIDocShellTreeOwner;
typedef void *JSContext;
typedef void *JSObject;
@@ -226,7 +227,7 @@ interface nsIFactory : nsISupports
[
object,
-uuid(59e7e77a-38e4-11d4-8cf5-0060b0fc14a3),
+uuid(6aef11c4-8615-44a6-9711-98f43805693d),
local
]
interface nsIMemory : nsISupports
@@ -236,6 +237,7 @@ interface nsIMemory : nsISupports
void Free(void *_ptr);
nsresult HeapMinimize(bool immediate);
nsresult IsLowMemory(bool *_retval);
+nsresult IsLowMemoryPlatform(bool *_retval);
}
[
@@ -521,7 +523,7 @@ interface nsIStreamListener : nsIRequestObserver
[
object,
-uuid(3de0a31c-feaf-400f-9f1e-4ef71f8b20cc),
+uuid(19501006-46e3-4634-b97d-26eff894b4d3),
local
]
interface nsILoadGroup : nsIRequest
@@ -536,11 +538,12 @@ interface nsILoadGroup : nsIRequest
nsresult GetActiveCount(uint32_t *aA
Re: [PATCH 2/5] wined3d: Introduce a wined3d_vertex_pipe_ops structure.
On 25 April 2013 11:58, Rico Schüller wrote:
>> if (!(fragment_priv =
>> fragment_pipe->alloc_private(&arb_program_shader_backend, priv)))
>> {
>> ERR("Failed to initialize fragment pipe.\n");
>> +fragment_pipe->free_private(device);
>
>
> Shouldn't that vertex_pipe->vp_free(device)?
>
Yeah.
Re: [PATCH 2/5] wined3d: Introduce a wined3d_vertex_pipe_ops structure.
On 25.04.2013 09:59, Henri Verbeet wrote:
-static HRESULT shader_arb_alloc(struct wined3d_device *device, const struct
fragment_pipeline *fragment_pipe)
+static HRESULT shader_arb_alloc(struct wined3d_device *device, const struct
wined3d_vertex_pipe_ops *vertex_pipe,
+const struct fragment_pipeline *fragment_pipe)
{
struct shader_arb_priv *priv = HeapAlloc(GetProcessHeap(),
HEAP_ZERO_MEMORY, sizeof(*priv));
struct fragment_caps fragment_caps;
-void *fragment_priv;
+void *vertex_priv, *fragment_priv;
+
+if (!(vertex_priv = vertex_pipe->vp_alloc(&arb_program_shader_backend,
priv)))
+{
+ERR("Failed to initialize vertex pipe.\n");
+HeapFree(GetProcessHeap(), 0, priv);
+return E_FAIL;
+}
if (!(fragment_priv =
fragment_pipe->alloc_private(&arb_program_shader_backend, priv)))
{
ERR("Failed to initialize fragment pipe.\n");
+fragment_pipe->free_private(device);
Shouldn't that vertex_pipe->vp_free(device)?
HeapFree(GetProcessHeap(), 0, priv);
return E_FAIL;
}
