bigmuscle

Nice, yes.. the dialog informs about wrong UDWM.dll or DWMCORE.dll. I could use MS symbol server to download matching PDB file and automatically find required offset, but currently I don't want my application to connect to any remote server.

Except the thing that DWMGlass injects into every process which is linked with USER32.DLL and I don't even know what the csrss process is

For anyone who has problems with 0.8 and gets only full transparency without blur effect - could you try this debug version? I've added a few things which could help. It does not give you anything if you have no problems (except message boxes informing you about incompatible DLLs if you have such) http://leteckaposta.cz/306250185

Yeah, I know Win7 colorizes it and I will put it here too but it was just some additional work which is not so important.

It shows correct callstack when you have PDB files which match your DLL version. The most important is DWMGlass.pdb which is distributed with my utility, it generates logs for my code. The rest (d3d11.pdb, dwmcode.pdb etc.) are for displaying callstack in Windows components and are not so important.

ORelio, I predicted this would bite people in the behind. You should consider a version of AGTweaker that doesn't move files around, but uses the one(s) BigMuscle provides and allows users to be responsible for placing them. Your software could locate the file (e.g., in the current folder, or in the path) and put the correct path in the registry. BigMuscle, no comments on the visual glitches that look like they're involved with the drop shadow? Edit: Here's the Debug.log from my system: http://Noel.ProDigitalSoftware.com/temp/Debug.log -Noel I think I already wrote about it some time ago and I'm afraid that I am not able to do anything with this. I noticed that this happen for me only if you have two or more occluded windows and drag with another window over them. The problem is that it does not have the data for generating blur effect at the edge of the clip region.

MrGRiM: sorry but new version does not contain Direct2D mode (always force to be off) and the bug you show in your picture has already been fixed. I think you are using invalid DLL.

But I guess it won't be the problem. Layered windows work here without problem. Also, Rayn19's log shows that hooking has been successful, only autocolorization hook failed (which should not influence it at all). There must be something more.

Windows Blue is under testing so to be expected I would imagine. BigMuscle is working with RTM. Yeah, I guess it will work on next Windows without a problem but it will need to pack shader programs (two very short files) together with my application. These files are very simple so it is no problem but I don't want to do it now because I can reuse that one in Win8 DWM.

Oh, snap! You're right I have udwm.dll ver. 6.2.9200.16384. And you are testing it now on different system than before? I'm interested where to get the newer version, but automatic Windows Updates should be enough.

It would make sense. In such case it will fallback to layered windows. And l guess layered windows are rendered into some intermediate render target. I have to test it.

Just a technical thing -> multi-monitor fix + delayed blur on new windows + non-working blur effect seem to be three connected things. I know that it does not help much but maybe someone gets an idea. DWM has two different render targets - I would call them surface RT and display RT. Display RT target is that one which you see on your screen and everything is rendered to. Surface RT is used for rendering e.g. window-open animation (etc.) and then it is rendered into display RT (this is the reason why there is no blur on animation and a while after, because there are no background data when window is rendered at that time). Now we must find a reason why your display RT target is marked as surface (i.e. it has been created with the flag D3D10_BIND_SHADER_RESOURCE). The previous version worked because I checked for surface and RT resolution (and that's why multimonitor didn't work). Now I can't check the resolution anymore, so I must find a bit different solution. Native mode does not perform any check. That's why the frame is completely black during opening. Could you provide your debug logs please?

AERO GLASS for WIN8 BETA 2 * do not generate occlusion rectangles for glass windows --> WS_EX_LAYERED bit is not set anymore --> works for compatible udwm.dll (6.2.9200.16420) only, in other case it will fallback to the layered windows * render blur effect only if DWM is attempting to draw glass --> fixes rendering blur effect on solid-color surfaces --> works for compatible dwmcore.dll (6.2.9200.16433) only * blur resources sizes are set according to render target size and not the primary monitor resolution * removed support for Direct2D mode --> Direct3D mode is supported now only, because it would be hard to maintain two different blur implementations --> Direct3D mode is more native, it uses internal DWM pixel shaders and respects DWM colorization settings * added option to render blur completely NATIVELY --> HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\DWM:UseNativeBlur (DWORD values 0x0 (default) / 0x1) --> works for compatible dwmcore.dll (6.2.9200.16433) only and it probably becomes unusable with future Windows updates --> very glitchy, because I returned only a very small portion of the removed code --> it is just a preview to compare visual and performance differences --> do not report bugs when you enable this feature * fixed DwmpGetColorizationParameters function which resulted in invalid stack in some cases * use correct Gaussian weights from Win8 RP * do not render frame color until the window is fully opened (Win7 behaviour) * reimplemented the colorization algorithm for transparent windows --> works for compatible shell32.dll (6.2.9200.16496) only when injected into explorer.exe Features marked as "works for compatible DLL only" may work for different versions too but only if it contains expected function on the same address. These features won't probably work under 32-bit version because I was not able to read the addresses yet. It can be read in debug.log whether the certain feature is enable or failed due to assembly mismatch. https://developer.berlios.de/project/showfiles.php?group_id=13124

Yes, I could. But I would have to download it from my MSDN account at first and it will take ages with my internet connection. And it is too much time when I need to read only some DLL offsets in debugger.

Anything to look forward to in the new version? Can't wait. Of course, many bug fixes and mainly things which are the most important for making the glass effect reimplementation complete :-) Unfortunately, I can't make work these new things in 32-bit version :-(

I already said it. DWM itself draws visual components into Direct3D surface. In Direct2D mode, you must create different layer where you redirect Direct3D component, process Direct2D rendering and then render everything back into Direct3D surface. With this you must maintain many resources such as DXGI surface to provide D3D-D2D interoperability. Even Direct2D is just an API above Direct3D 11, so it becomes complicated as hell. In Direct3D mode, you just set vertex buffer, vertex shader, pixel shader, constant buffers and render. That's all. Yeah, the DWM colorization is a bit complicated. In fact, the final color is computed as (ColorizationColor * ColorizationColorBalance / 100), then afterglow color and blur balance is applied. The final result is then influenced by blur weights. But pixel shaders and DWM completely take care about this. Unfortunately, in Win8 RTM, the color (and balance) is always managed and computed for opaque frames. The next version will change the algorithm to the original one which computes for transparent frames.

Good idea. However, I would like to stop the discussion about this. I'm going to provide new development version soon, so I want to keep this thread clean so I can track any reports.

This is not about perfect version. It is about the fact that this is still the development version only which has its own roadmap. And it will be released when it is planned to be released and not when you say it. Yeah and that's the point. I could make the program private and provide it to closed group of testers only and publish the screenshots only. What would happen? People would start shouting that it is fake and they want it too. So I provided the development version to the public. And users come and shout that they can't use it for regular usage (you can check e.g. WindowBlinds forum, the same happens there, just the developers didn't released anything to the public)

It is written above. The message box appears approx. once an hour and it is enough time to see whether the game lags or not. Sorry for this, but I have approx. ten years experience that people does not want to test anything. They want to use it for free, nothing more and when some problem appears they starts shouting that the software is sh*t and think that I fix the bug in 5 minutes and send them fixed version immediately. That's my experience and unfortunately this software confirmed it again you can read this topic and you find people complaining in caps lock many times about some problem and if I tell them that I have not found a solution yet, they complain again and again... The popup is an issue only if you don't want to test anything - or do you thing that user who downgrades to old "popup-less" version wants to test anything? It makes no sense to report already fixed bugs There are given some conditions of the software usage. If you agree with them, use it. If you don't agree, don't use it. Simple! If you are trying to find a way how to use it against the given conditions then it is same as using cracked software. Maybe it is problem that you have UEFI secure boot enabled? No solution for it yet :-(

I already wrote about this some time before. All the versions are not intended for regular usage. And it seems to me really stupid that many people install this software and instead using it for preview/testing, they start searching for the way how to remove background console window or skip startup dialog. Ok, so I removed the console window and added a thing to promptly inform them that this is really not for regular usage. If you want to use it for customizing your computer then it is not intended for you - do not use it and wait for final version. It is very simple, does the message box nag you? Then there is something wrong. And it's the fact that you probably use it for customizing your production system and not for testing/preview. If you use this piece of software for the intended usage then there is absolutely no reason why the message box should bother you. Someone complained that it makes impossible to play games because the message box kills the game. Ok, it's bad, but why you use experimental software while playing the games? It's illogical.

There is something wrong for you, just because it is technically impossible to load version 0.7 with the loader. The needed exports (required by loader) are not present in 0.7.

Do I understand correctly that you use old loader to load the current version? If not, then try looking into Log Viewer whether there is not some info why AppInit_DLLs failed to load. Also make sure that UEFI secure boot is disabled (I don't know whether you have already mentioned this)-

Well, I admit that this can look weird but this does not seem to be bug. If you look properly this happens even in Win7; it is just reversed there - Window opens with fully transparent frame, then the blur appears.

Post screenshot of your registry settings under [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows].

I don't think that it can be done per-window basis at this state. The main problem is that at the time when the content is rendered to the render target, window handle is not known so you can't identify which window is being drawn. But from my knowledge, the colorization is stored with each window visual in uDWM so changing it could work. I'm not sure about the stripes. The occlusion problem is fixable and I have already fixed it with the small exception that the uDWM occlusion technique does not deal with the blur radius. Thus there is a small glitch a few pixels around the inactive window border. I didn't have time to check this small problem.