pengipete

Beta working fine here - installed folder to C://DWM & edited .reg accordingly in notepad & then installed - then a quick reboot & bob's yer uncle. No noticeable issues - have rebooted half a dozen times, logged-in & out, switched users etc - all fine. No problems with Metro or any desktop apps I've tried so far. Tried various "advance settings" for Windows (fades, slides etc) - all working fine. No noticeable issues with SiB. No "feeling" of anything slowing down. If you or anyone else can give us a simple, reliable way to change titlebar font colour and/or add the "glow" around title text, I reckon that's a big downer of W8 sorted.

1.1.6 not working with AG v0.6 - I believe it's cos BM changed the name of the exe.

Translated that Chinese site (with google translate) and they aren't copying - they're correctly attributing to "a foreigner" and discussing it much as we are here (though obviously, without the benefit of being able to talk to BM.). There's a lot of posts there and they're pretty much the same mixture and type of comments we have here. The first post in the thread was a bit worrying as it appears to be providing a local link to the files but later ones include direct links to BM's files using his own links. They seem to be keeping up to date with versions and presumably, the discussions here (judging by the solutions being offered for problems). Overall, it's more like BigMuscle's Chinese fan club

What happens if you change the taskbar transparency setting in SiB? It may be that disabling start menu transparency but leaving taskbar transparency switched-on in SiB will get the right result. (I'm using those settings now and the effect is spot-on - very "glassy") If that is the case, might it be easiest to just check SiB's settings - rather than trying to chase the taskbar's location?

It's fine in d2d mode. Just spotted another "symptom" - pressing CTRL+ALT+DEL should open a plain-coloured screen with the various sign-out/switch-user type options. That screen is also totally transparent. On the metro screen (and I'm just using bog-standard metro - no tweaks or add-ons) the screen itself is a plain, single backgound colour with the patterned areas at the top and bottom just being two solid strips. Those patterned areas are fine - it's the section across the middle where the tiles appear that is just the plain colour that is transparent (or at least, being drawn with whatever was in that location on the desktop). The side-bar menus on the metro screen - such as settings - and the CTRL/ALT/DEL screen are also drawn using that single backdrop colour and those are all 100% transparent. I don't know the techie answer but in basic terms, it appears to be that backgound colour that is being affected. I've tried chosing a backdrop colour in metro that is completely different to my active and inactive borders on the desktop - just in case it was the colour itself that was the key but whatever scheme I chose, the background colour in metro is 100% transparent (note - no blur or variation on transparency). Also - deleted the old "glasstransparency" key from registry. Didn't remove the problem. In fact, caused a new one. Now, when I'm on the metro screen and open then close the charm bar, the image of the charm bar and the large grey clock remain and become part of the background in that central area of the screen.

No patches, hacks or themes here. The only application I have that in any way interacts with "metro" is StartIsBack and I've disabled and uninstalled that to check - made no difference. Another odd effect... On the metro sceen, open the charm bar then open settings - I can see the white icons but everything else is blank. If I then point to the top right of the screen - the charm bar opens over the top of part of the area where the settings options bar should be (that's normal) but when I move the pointer away from it, it remains visible - not selectable but visible - (as if it becomes part of the backdrop but hard to say because the settings "charm bar" is 100% transparent anyway) Aside from deleting the DeviceFeatureLevel key, I've made no other changes to the registry since V0.5.

V0.6... Caused black screen - but that's cured by deleting the DeviceFeatureLevel key from the registry. The transparency is fine but... The "metro" screen has now become transparent - the centre section where the tiles appear is now "see-through" and displays the desktop. Anything showing in charm bar - settings, wi-fi etc - is completely transparent - only the white text and the outine of the bar is visible. In fact, the charm bar itself is transparent when it opens and only becomes solid when you move the pointer over it. Dragging windows is very jerky. StartIsBack start menu becomes almost totally transparent - that's cured by disabling transparency in SiB's settings.

I didn't say it's a "problem WITH norton" - I said that norton may be taking a split second longer to initialise than is needed for that RSS fed wallpaper to connect. Tweaking your start-ups and settings - including norton - is likely to be all that's required. Try running with a regular, ordinary folder of wallpapers - not an RSS fed active one - REGARDLESS of whether or not you have some of the possible images already stored locally because the whole point of those RSS fed wallpapers is that the pc connects when you use them - to check for new wallpapers and updates. If that works, you will have a fair idea that the problem lies with establishing the internet connection quickly enough. Put simply - you have a small lag at start-up and you are assuming it's caused by SiB when there's really nothing to suggest that. It may be a slow internet connection or a slow start for your network card, maybe a slow start for norton or any number of other reasons - but there's no logical reason to say that SiB is causing this problem - and live wallpapers are a well-known a pain in the you-know-what.

I reckons that's the problem - you are using an RSS theme which gets the images feed to it through your internet connection. It's not SiB that'sgoty a bug - it's that your network connection isn't fully working by the time the desktop loads. What's most likely happening is that Norton is taking a while to inititalise and whilst that may be being slowed down a fraction by SiB starting-up, it's not specifically SiB - you'd get exactly the same problem no matter what application was running at start-up with the same priority. You may be able to cure the problem by tweaking Norton's settings - check for any option to begin initialising BEFORE the desktop is loaded cos even a fraction of a second earlier start may be all you need. Failing that, you need to check exactly what is running at start-up - even on a basically vanilla installation of Windows with no applications installed, it's likely that you'll have a load of unnecessary stuff running relating to sound and graphics cards (often really pointless stuff that just make help file load half a second faster). One other thing that you haven't mentioned - is your pc - especially the cpu and ram - up to spec? If your cpu is slow or you have very little ram, you're going to struggle to run live wallpapers and have more than the most basic start-up applications without this problem. The same applies if your broadband is slow - it takes time to download a hi-res image.

"pretty sure they are not broken" is no substitute for actually checking them. From your video, it's clear that a wallpaper is loaded - it then fades out which indicates that it is simply changing to a different picture rather than being unable to load and display on boot-up. Put together, that suggests that your desktop is loading correctly and the problem comes from displaying the second image - which appears to be changing very quickly after you log-in. If you google for "blank wallpaper" or similar, you'll find that this is a problem going back years - to at least XP. One suggested "cure" (and there are lot sof possible cures) is to disable "shuffle" but that's most like simply down to preventing a problem image from being loaded immediately after boot-up (if it's the tenth image and there's a 30 minute delay, you'd have to use the pc continuously for 5 hours before you'd see the problem). Basically though, no-one else is reporting the same problem as you and I've tried to recreate it and can't - which means it's pretty-much impossible for Tihiy to try to find a possible cause in his program until you have at least tried to eliminate likely causes specific to your pc. Please check the pictures as I suggested - maybe try to create a different slideshow using images from a different folder or download a new theme from Microsoft's site - most importantly, check if this problem occurs with the built-in themes and pictures and any that you have created or downloaded. If the problem is happening with every slide show regardless of what theme, storage location and image format you are using, we can try to work out if there's any way that running SiB could possibly be involved. Also. can you tell us some useful information - such as the delay you have between slides, whether or not you are running any tweaks or hacks (such as gui themes, transparency apps etc) and any other start-up programs and apps you have running - just in case there's something hogging your cpu/gpu at start-up - if that's the case, it could be that stopping any one start-up item would release a few clock cycles rather than it specifically being down to SiB. If you can definitely eliminate every BUT SiB, then we'll need to know details such as the version and your specific settings to be able to start to work out where the problem could be.

Vibbow... It looks to me as though you may simply have a blank or corrupted picture included in that "slideshow" - we at least need to eliminate that possibility. Try the following - open the "personalise" window and click on "desktop background". Check that there are no blank images showing and ticked in the window and if there are, un-tick those (then exit and save). If all the images have correct thumbnails, click the "clear all" button at the top of the window then go through each image in turn - as you click it, the desktop wallpaper should change immediately. If you get a blank desktop, make a note of which image it was but continue until you have check every image in that folder - just in case there's more than one. If you find images that "don't work" you can exclude them from the slideshow. As to why certain images may cause the problem - it depends. It could be that they are corrupted or it could be a broken codec. If the images you are using are standard ones from the Windows installation, you may be able to "repair" them using SFC /scannow. If they are your own or downloaded images, it could be that the folder location is causing a problem - so make sure they are in an "approved" location such as your "My Pictures" folder. If you are using any codec packs, it's also possible that there's a problem there so you may want to trying removing the codecs and seeing if the problem exists without them - if so, shop around for a better codec pack. If none of the above works, post back. I should add that I have tried to reproduce the problem and can't so it doesn't appear to be universal - hence suggesting that you eliminate anything that could be specific to your pc.

You need to set it lower - high numbers = less transparency. Somewhere between 130-170 seems to be pretty decent if the blur level is set to around about 30. Alternatively, you could try Orelio's AGTweaker - a GUI that lets you adjust the various Aero Glass settings without needing to use the registry - you can download it from - use V1.1.6 with Areo Glass V0.5 and it works very well.

I was only thinking of it with AG being in the development stage - so people testing it are more likely to be entering settings manually.

Nice one. Just a suggestion though - might be best to leave the D2D key and just set it as required by BM's app - apart from anything else, there will be people who created the key manually and it's "bad manners" to delete their keys I like the way you think though - cleaning up as you go along is admirable

1.1.5b correcttly reading and writing to HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\DWM and if that "folder" is missing, it is created. Note:- Don't know if it's intentional but if the "Use Direct2D" box is selected in AGTweaker 1.1.5b, the HLKM\....\Windows\DWM\UseDirect2DRendering key is deleted rather than its value being set to "1" (double-checked and the key is totally absent - it's not being created elsewhere in the registry). Aero Glass does switch to D2D and without that key present, it remains in D2D after being stopped and restarted - which suggests that it's running in D2D by default (so anyone who doesn't have the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\DWM is not running D3D even if they think they are).

I didn't "complaint that your program has a bug" - I reported something that wasn't working correctly on my pc and explained that I had found the reason for it. The reason I mentioned AGTweaker is that a number of people reading this thread are likely to be using it and and if they are having problems with Aero Glass, it seemed sensible to tell them that the latest versions of both applications are not quite working in synch - so if someone tells you that "it's working perfectly at 9300 on my XYZ graphics card, that might not be true because they are actually running the default 9100 setting. That was nothing to do with "complaining" - it was to try to warn you that there could be bugs or problems you will never find because a lot of people are running at default settings without realising it - such as the 9100 value - and you've said several times that you'll be changing those in the final version. That makes it possible that people will be telling you that it works with such and such settings when, in reality, they are using totally different ones from what they think they are using. I was just trying to help - reporting something that could result in you getting inaccurate feedback and maybe trusting something that has never actually been tested.

BigMuscle... I think you are missing the point entirely. You are asking people to BETA TEST your app - so you NEED them to mess around and see if there's anything they can do that will break it. If they are all running it with your default settings, they are not beta testing - they're just using it. The point is that your app is reading and using values which may or may not exist in the registry and if they don't exist, it runs at your "safe defaults". If those "safe defaults" are all you ever plan on using, there is no further need for beta testing - but if you are still trying to work out what works best or looking to develop futher, you need people to fiddle about. You have specified that those registry values exist and have even ASKED people to test them on more than one occasion - so I'm just trying to tell you that it's not possible to correctly beta-test an application when you can't test all of the possible variations and settings. A prime example - the black screen that many people are reporting is usually avoided by using 9100 - but unless you have people willing to try the other values, you'll never know WHY that is causing what appears to be a more-or-less random and unpredictable problem. If you are leaving that at 9100, you should remove the setting from the registry rather than now saying that no-one should change it. If changing a registry value that your app uses causes or highlights a problem, that's not a failure on the part of the beta-tester. Unless they are sticking in values that the operating system can't even handle, then the application needs to be able to deal with them. It may be okay for now to say something like "x is never more than 200" - but all it takes if for some external app or even Microsoft to make a small change and that value may suddenly be set to 201. If all you want is for people to run your app and tell you that it doesn't simply crash when run, you shouldn't be listing the registry values it uses. If you list them - and even ask people to try changing them - you shouldn't be critical of those who try to help by testing every value and setting. It's also a bit unfair to assume that just because someone is not 100% clear on how a handful of regsistry values interact with your application (or DWM in general) that they are totally ignorant and shouldn't touch the registry.

With this thread getting so large now (approaching 600 posts), It would be a good idea to include a Changelog from you of new previews, including which reg key or keys are affected, should and should not exist with proper recommended settings etc. I've previously asked for that - and asked that they (and any future updates) be added to the first post - because they are nowdramatic spread throughout nearly 600 posts and the changes are quite dramatic at times.

That's precisely what I was trying to tell you - the registry keys HAVE been crreated in WOW6432Node - and it appears they are created there by AGTweaker because I completely removed them and they stayed deleted until I ran AGTweaker again - and then they reappeared. I ran AGTweaker and it appeared to allow me to use 9200 & 9300 - which never worked for me in your previous betas BUT inn reality, it Aero Glass wasn't using those values when using D3D - it was always running at 9100 - so anyone beta testing and using AGTweaker will be erroneously reporting that it works with those settings. Regarding "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" - are you saying that everyone here apart from me manually created the entire HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\DWM "folder" and all of the keys in it - because it quite simply did not exist on my installation of Windows 8? Does that mean there is and always has been a problem with my installation - because I've had no problems with it at all - or did I just completely miss a step when running V0.5? Please understand - I am NOT talking about blur or anything else when refering to those missing registry values in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\DWM - I only discovered those keys were missing whilst trying to work out why I could not get coloured inactive borders BUT that is just coincidental - it caused me to discover the lack of the HKLM entries was stopping AG from working as expected - I've resolved that problem and am just trying to warn you that V0.5 does work but without those HKLM keys, it is only running with "safe defaults" - so the beta-testing is not actually testing anything.. I'm trying to get you to see that if Aero Glass relies on reading values in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\DWM and that "folder" and the keys it is supposed to contain does not exist, the app will work to a certain extent but will not be working correctly. What features do work are the basic ones you've had since the first beta so anyone testing V0.5 is not really testing the latest changes you've made. As you can see from post # 561, someone else is now saying that their registry keys - the ones which determine whether D3D is used and whether it's set to 9100, 9200 or 9300 - are in yet another location. Are you saying that Aero Glass will still work no matter where those keys are - or is that person not actually using the values they think they are whilst testing? As you know, with no other values changed, the overall Aero Glass effect looks quite different if you switch between D2D and D3D. It was only after I found that the HKLM folder was absent and manually created it that I was able to see that I had, in fact, been using D2D. I'm suggesting that other people who have said that it works for them may actually be using D2D without realising it - so they are not actually testing the new/updated routines you've added. Again, I'm asking if some of the other people testing this could please check their registry and make sure that they have the correct keys in ALL of the registry sections applicable. Aero Glass will work with some of them missing but it may not be doing exactly what they think it is - such as using 9100 when they think you've set it to 9300. If that is the case, it may appear stable but they aren't actually testing V0.5 - just using the basic DWM hook which has worked since V0.1.

I cut and pasted "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\DWM" directly from BigMuscle's post #506 - the one in which he announced V0.5 and listed the keys. The key you suggested - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DWM - does not exist on my laptop The key HKEY_CURRENT_USER\Software\Wow6432Node\Microsoft\Windows\DWM was not created when I ran Aero Glass - it only appeared after running AGTweaker and the settings for D3D it contained were not applied to Aero Glass.

Orelio... I believe there's a bug in V1.1.5. The Aero Glass values that belong in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\DWM are being created in and read from HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows\DWM by AGTweaker - so they are actually NOT being applied to Aero Glass. As far as I can see, that means that AG is always running in D2Dmode regardless of what AGTWeaker says (or "thinks") it is doing. I've also found that - on my laptop, at least - the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\DWM "folder" was completely missing - which I have reported to BigMuscle as a possible bug in his application.

Turns out that the lack of the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\DWM entry was the problem - that "folder" and the entries it was supposed to contain had been created in HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows\DWM for some reason - presumably when V0.5 was first run given that I know I've never created those keys anywhere. Edit - seems that the entries in WoW6432Node are created by AGTweaker - but that's separate from the problem that the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\DWM wasn't created in the first place. Given that the dafault if to use D2D - which appears to be more "stable" for more people is it possible that there's a bug and that HKLM entry is not being created - resulting in everyone running in D2D without even realising it (as they must be if the HKLM keys are missing)? Since no-one but you and I has actually said that they are testing D3D and inactive border colouring (and NOT using any non-standard themes or GUI patches), I can see how such a bug - if it exists - could go completely unnoticed. I also note that since V0.5 was released, there has been no further mention of problems relating to DeviceFeatureLevel settings - which may support the idea that everyone is actually running the app in D2D without even realising it. I've drop a note to ORelio to warn that his AGTweaker app appears to be setting keys in the wrong part of the registry but that should only result in his app showing the wrong values - it wouldn't delete the correct HKLM folder and simply wouldn't send any of those values to Aero Glass. Can someone please check to see if the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\DWM entry in the registry exists - someone who has never manually created any such DWM "folders" and entries.

On the screen-grab of your registry values, you have GlassTransparency set to 0 but your window borders are mostly opaque. If I set GlassTransparency to zero and duplicate all of your other values, I get totally colourless, transparent windows with a slight blur - nothing even remotely like your screen-grab. It's not helping that the information for each update is buried somewhere amongst 550 (and rising) posts but it seems that v0.5 should have a DWM entry in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\DWM - but that "folder" doesn't exist in my registry. Is it something I have to create? And what about the DWN registry "folder" that was in HKEY_USERS\.default - should that still be there or should we delete it now? I should add that I've asked in the forum if anyone else is getting the inactive coloured borders (without additional apps, themes or hacks) and no-one has replied - hence asking you.

I copied your registry settings exactly - and got completely transparent borders with no colour at all - and then I noticed that your window gadgets are not standard Windows 8 ones. Are you using a custom theme or gui - cos your settings simply don't work on my bog-standard W8.

Sorry to be a pain but you lost me completely What is "GlassColorization" - is it a registry value cos if it is, I don't have it in my registry? Without any technical detail on how it works, can you say whether or not it's possible to have inactive window borders set to a colour other than the default grey when using the D3D mode. I don't mind how it works - I just want to know if it's possible. I'm really confused because you seem to be saying that the inactive border should already be "tinted" with the colour of the active borders when using Aero Glass in D3D but I am seeing absolutely no colouring - even tested that by dramatically changing border colours, taking screen grabs then checking the inactive border colours in photoshop - they are identical. At the moment, if I use Aero Glass in the D3D mode, I can only have grey inactive borders - always and only exactly the same "dead man's skin" shade of grey and that doesn't change no matter what I do with the active window border colour. If I use the D2D setting in your app, I can have the inactive borders any colour I like - so it seems to me that using D3D is a step backwards - it may be technically more "better" but it seems that it lsoes a valuable feature. If you are planning on dropping the D2D method, it will make the app less useful for me as changing the inactive border colour is at least as important as having transparency.