bigmuscle

Registry settings are still the same (HKEY_CURRENT_USER\ etc.). However, this version uses Direct3D mode as default so I recommend not to use GlassTransparency settings at all (either delete it from registry or set it to zero) else it will interfere with default DWM colorizations.

I do not force anyone to use it, if you don't want to preview new version, you don't have to.

AERO GLASS FOR WIN8 PREVIEW 6 * default device level changed back to native one, --> if glass does not work for you, you must play with HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\DWM, value DeviceFeatureLevel (DWORD valid values: 0x9100, 0x9200, 0x9300, 0xA000, 0xA100, 0xB000, 0xB100) - do not touch this settings if everything works for you because it switches your graphic card into old compatibility mode!!! * removing window layered bit when window border is removed --> this should disable layered window on fullscreen application, if it does not help, I will try to complete disable all layered windows and not to render blur effect when fullscreen window is on top * removed Direct3D COM object hooking and replaced with proxy objects * added one-hour preview notification (yes, sorry, but this is still preview only) * fixed BlurDeviation settings * fixed crash/graphics glitches when theme generates more vertex count than expected * fixed memory leaks when graphic adapter is removed * render taskbar background when high color intensity is set * Direct3D mode is default * added possibility to load glass with system --> WARNING!!! This feature is for very experienced testers only, because it enables that glass will be loaded directly with DWM process. When glass loading fails, your computer becomes unbootable!!! --> Registry script attached, modify it to match the path where you extract downloaded files (change LoadAppInit_DLLs to 0 to disable loading) --> You can hold CTRL key while DWM is being loaded (e.g. just before logon screen appears) to avoid glass loading (DLL is still loaded but no functionality is activated) --> Debug console is not displayed when glass is loaded this way --> this kind of loading does not suffer from random black screen like classic loader does https://developer.berlios.de/project/showfiles.php?group_id=13124 When important bugs of this preview are fixed, I would suggest to enter betatesting phase for 1.0 release. After then, I will concentrate on adding new features (Flip3D for example).

I'm sorry but I am not sure whether this is achievable. In the past, I managed to disable desktop composition in Win8 but it required to use Win7 Explorer else you ended up with the black screen only. I guess that Win8 explorer depends on DWM to be running else it is not able to draw anything.

Then it must be bug. Value 0 should disable blur effect completely. Thank you. Unfortunately, the window is not set as layered, so I can't say what could be the problem

Could you check the fullscreen app window styles? E.g. via WinID utitlity - http://www.dennisbabkin.com/winid/ ... it will be difficult to check but I believe it is possible somehow - run WinID, run your app, move mouse pointer when it is in fullscreen, press right SHIFT (click sound should be heard), go back to WinID and check "Captured shots in upper menu". Copy the info here.

Also, BlurDevation settings has no meaning in Direct3D mode.

AeroGlass since v0.4 does not blend layered windows into desktop when alpha value is 254 - it just simply draws the window and blending is rejected (yeah, but the content behind it is still being redrawn). Also, when window does not have a border (which should be the case of any full screen app such as games), it is not set as layered. It brings me an idea that it can have problem when the application creates the normal window with the border and later changes it to borderless fullscreen. In such case, the window would be layered. MagicAndre1981: Up to Windows 7, Desktop Composition is disabled when some application requires it. But since Windows 8, it is not possible to disable Desktop Composition and it is always enabled.

Peacem4k3r: it's the theme which was discussed here some pages back - that one which causes the Aero Glass to crash.

Of course, crash will be fixed in next version. But I do not intend to implement rounded corners directly into my utility.

Firstly, you should update to the latest version because your crashlog comes from the version which was not generating crashlog properly. Then, if you do, don't use Win7 theme. It is known to crash. I am not absolutely sure, but it seems that rounded corners comes from visual theme too. At least, the theme Win7forWin8 somehow achieves rounded corners on taskbar preview windows. (Therefore, it generates more vertices than my AeroGlass expect and it crashes). But I won't add them to my utility, it would require complicated vertex buffer modification and I have even the problem to modify vertex buffer to extend rendered edges by blur radius :-D

ouch, this seems to be the bug in my application. When DisableLogging is set to 1 then the logging should be disabled. However, it is not a big deal because it is not recommended to touch this settings.

try to search how to disable key virtualization... as I remember correctly there is some article at MSDN

Nope, the low-level settings is under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\DWM This application does not change anything so there is nothing to uninstall. I will provide it as soon as possible, however I can't ensure that it will work (just because I have x64 systems only).

Sorry, but you are probably in the wrong thread. This small piece of software never entered in betatesting state, it neither entered in the alphatesting stage. That's why I always highlight that each version is experimental preview only. It's purpose is not to test anything, it's purpose is not to hunt for bugs etc. and I have never said that (the only testing request was about GlassTransparency and BlurDeviation settings, not others!). The only purpose of this version was to show "hey, blur effect is possible and it may look like this!" and to show which direction it will take, and that's why the preview dialog will stay there. The registry setting is there only for a) HKCU for preview only - to show possible future features, B) HKLM if anyone experiences some serious problems... and yes, you are right, there is absolutely no reason to have any registry settings because believe it or not, the hardcoded values work really at its best (just because they are not hardcoded by me, but by DWM itself). Also, the black screen problem has nothing to do with DeviceFeatureLevel, it is totally different problem. It is just limitation of the loader which is not possible to fix it (without "hardcoding" my library into system) and I already explained it. I am not critical about changing registry settings. I am just critical that you change registry using some 3rd party application (which changes totally different keys) and then complain that my utility has a bug because it does not create key XYZ and thus the settings does not work. DosProbie: as I have already said, the registry settings are not highlighted in the first topic just because it is temporary thing only. Settings such as DeviceFeatureLevel will be removed when I successfully fix the issue and it will use native level (i.e. 9100 for D3D 9.1 video card, a000 for D3D 10.0 video card, b000 for D3D 11.0 videocard etc.). It is only my good will that I added the settings to enable preview on unsupported videocards. Just a small example, there is tons of registry settings in Windows itself, keys nor values do not exist in the registry by default and you don't find any list of them - just because you are not intended to change them. There is also hidden MinFeatureLevel and MaxFeatureLevel directly in Direct3D library ;-)

It seems that you absolutely miss the point why any registry settings are there. Any registry key/value (and it pays for all cases, not only this utility) is intended for experienced users only and it should be touched only if you know what the key/value is intended to do. Application has hardcoded default values and does not rely on the existence of any key. When no registry setting is modified, then application works exactly as it is intended to work - so it is absolutely wrong statement that application "will not be working correctly" when any key/value does not exist. Registry values under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\DWM are there only for technical reason and they should not been touched at all if you don't know what it really does. Therefore, the key does not even exist in the default state. And there is absolutely no reason why this key should exist and why application should rely on its existence. And nobody ever said that this key is supposed to exist in default state. So again, if the key under HKLM does not exist, then this application works at its best... there are only certain special reasons why one should create this key and change the default settings. But I strongly say DON'T DO IT! And what more, don't change them via any external 3rd party application which probably touches totally wrong keys - and I won't provide any support if you use any "GUI application", because it is totally beyond the scope of my utility (just because the keys such as WOW6432Node have nothing to do with my work so it is only your responsibility if you manage to create them by whatever way) All user customization settings are placed under HKEY_CURRENT_USER key. But again, it is still Windows registry, so you should not touch it if you don't know what the key/value does! To DosProbie (post #561), I say again - there is no WOW6432Node supported by this utility. Also HKEY_USERS\.DEFAULT is valid only for pre-0.5 previews.

It seems that you miss the basic thing here. AeroGlass utility does not create any registry key nor modify any other system settings and it is not intended to do so. It only reads the values which you create on your own. Since the registry settings is still current development issue I have not put them in the first post but they can be found near last changelog only. Also, there is no reason why the settings should be read from Wow6432Node because this utility is fully 64-bit. The global settings is read from HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\DWM and the local (colorization) settings is read from HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM. (some settings can also work in other keys such as HKEY_USERS\.default etc. but it is only due to fallback when normal values has not been not found and nobody should modify these keys at all so ignore this small note :-) ) DeviceFeatureLevel has nothing to do whether blur effect is rendered via Direct3D or Direct2D. It states the graphics device compatibility mode which DWM uses (just because it is always Direct3D - also Direct2D is just an API layer above Direct3D 11). In 0.5, I put the default value to 0x9100 (if settings is not found in the registry) thus nobody complains about this settings now. My goal is to make everything work with native device level.

Because I use different theme resource which is not fully transparent as RTM theme. RTM theme looks like this no, colorization settings are stored in HKEY_CURRENT_USER yeah, it's true because RTM theme is totally transparent with thin line around the border. RP theme has semi-transparent texture in the border. It looks like device failed to be created in some cases. Could you try playing with DeviceFeatureLevel? Maybe, your card does not accept level 0x9100 correctly.

Used theme does not influence it at all. It is just glyph which is placed over the blurred and colorized border. I just tried with default Win8 theme and no problem - the color is just bit more intensive.

Sorry for confusion. I meant GlassTransparency settings. And yes, it is possible to colorize inactive borders in Direct3D if you respect the rule I wrote above.

Normally the inactive caption color is hardcoded to RGB 235,235,235. That's DWM "feature". a) If GlassColorization is > 0 than alpha value of caption color is set to this value and blended into the blur effect. When GlassColorization is 0, then this color is completely ignored and nothing is blended into the blur effect. This is valid for both Direct2D and Direct3D. But I recommend to set this value to 0 in Direct3D mode, because this mode is almost native and should not use this kind of colorization (it is there for backward compatibility only and it will be removed in the future) B) In Direct2D mode, when ColorizationColorInactive is set, then every try to render solid 235,235,235 is replaced by value of this registry settings. c) In Direct3D mode, blur effect is rendered via DWM pixel shader which itself colorizes blur result with color in ColorizationColor multiplied by ColorizationColorBalance. However, for inactive captions, I've added a feature that it uses ColorizationColorInactive multiplied by ColorizationColorBalanceInactive instead. By default, ColorizationColorInactive has the same value as ColorizationColor but ColorizationColorBalanceInactive is set to 12% (it is approx. 80% for active captions) therefore the result color may look much more greyish. Anyway, don't forget about a).

pengipete: this is how it works in Direct3D mode. Inactive caption color is set to the same value as the active caption color but the color balance is set to 12%. You can play with ColorizationColorBalanceInactive, ColorizationBlurBalanceInactive and ColorizationAfterglowBalanceInactive to achieve different color shades but if you don't touch ColorizationColorInactive directly than inactive caption color will always be derived from current active captions color. Also colorization settings (even for inactive captions) is automatically reloaded when you touch it in control panel (starting with v0.5). But as I said at the beginning - this works for Direct3D mode and I won't change it in Direct2D (just because I take D2D version as feature-frozen and I want to completely remove it when D3D mode works completely).

This came happen for one certain reason: if(currentPixelShader == glass->getTextureAlphaPixelShader()) { D3D10_TEXTURE2D_DESC textureDesc = { 0 }; texture->GetDesc(&textureDesc); // FIXME: taskbar is currently recognized by its size. This can probably break some things when other alpha-blended control with taskbar size is drawn RECT taskBarRect = { 0 }; GetWindowRect(FindWindow(L"Shell_TrayWnd", NULL), &taskBarRect); if(textureDesc.Width == (taskBarRect.right - taskBarRect.left) && textureDesc.Height == (taskBarRect.bottom - taskBarRect.top)) glass->drawGlass(VertexCount, StartVertexLocation, false); } Only taskbar, menu shadows and window icon (and windows which uses SetWindowCompositionAttribute) are drawn with pixel shader which respects alpha channel of the texture. So when the texture size is equal to taskbar size then it must be taskbar. Thus your application behaves in non-standard way... or do you have different taskbar size then the default one?

Practically, it can't work, because 0.5 uses different registry keys than any previous version.

Values in registry depends on settings selected in control panel and are automatically generated if you select auto-colorization.