Is your computer a notebook and it has 2 integrated video cards, such Intel and nvidia, ie.? I had similar behavior even on the IDE, so I got fixed by force Delphi use Intel only (my case was by setting up at nvidia application manager)
Yes, if I attach the nVidia card to bsd.exe, the IDE work well. But if I attach the Intel integrated card to the compiled application, it work fine also...so the IDE should works with an "Intel HD Graphics 4000" card...no ?
Paul TOTH Yes, that's correct, specify bsd.exe to work with Intel (integrated) will fix. I had that behaviour even when moving a single TButton or label on the IDE with Windows 7. I notice that after upgrade to Windows 8 that fix was not necessary, at least moving TButtons are ok :), but I did not tried using 3D, so if it happens I see I will need to force integrated graphics (Intel).
"Your laptop uses a technology called Nvidia Optimus to render video output from two GPUs (the integrated Intel graphics processor, [IGP], and the more powerful Nvidia graphics card [DGPU]). This is accomplished by connecting the laptop's screen to the framebuffer of the IGP only, and allowing the DGPU to write pages of memory directly into that framebuffer. In this way, both cards can render output to the same screen, even simultaneously. When an application calls for DGPU rendering, the DGPU writes output to the portion of the screen that the application occupies. In the case of a full screen application such as a game, the DGPU will write to the entire framebuffer of the IGP"
in fact "White" in the IDE should be $FFffffff, but it acts just like $00ffffff. I have the same bug with any color with a null alpha channel ($00ff0000, $0000ff00 ...).
(haven't used FM, yet), maybe the runtime has a bug, by ignoring the alphavalue of the color, which ends up in a 32bit color value with an alpha of 0 which tells i.e. directx to fill the screen with an invisible color, which means it'll never fill the background. And maybe there are situations where it creates only a 24bit(R8G8B8) Rendertarget, where alpha is always ignored? Just wild speculations.
Paul TOTH If it uses a 32Bit Rendertarget(A8R8G8B8) as default, it seems natural that a color with 0 Alpha is invisible. This tearing is what occurs when the screen is not cleared before the next drawcall and not all old pixels are overwritten by the new geometry.
Are you developing in a VM? Are you sure 3D acceleration is active?
ReplyDeleteno I'm on a MSI GE70 under W8...this appends only with a Form.Color := White (default), the color $FEFFFFFF is white without bug :)
ReplyDeleteI don't see this behaviour. I'm using Delphi Enterprise XE5 Version 19.0.14356.6604
ReplyDeletesame release under Windows 8 6.2 (Build 9200)
ReplyDeleteWindows 7 x64 pro sp1 with NVidia Quadro4000.
ReplyDeleteTry updating your video card driver.
ReplyDeleteIs your computer a notebook and it has 2 integrated video cards, such Intel and nvidia, ie.? I had similar behavior even on the IDE, so I got fixed by force Delphi use Intel only (my case was by setting up at nvidia application manager)
ReplyDeleteRAM overloooaaaaadddd?
ReplyDeleteyes they are 2 graphic cards, Intel & nVidia...don't know wich one is used (Intel I guess)...note that I don't have this bug at runtime
ReplyDeleteYes, if I attach the nVidia card to bsd.exe, the IDE work well. But if I attach the Intel integrated card to the compiled application, it work fine also...so the IDE should works with an "Intel HD Graphics 4000" card...no ?
ReplyDeletePaul TOTH Yes, that's correct, specify bsd.exe to work with Intel (integrated) will fix. I had that behaviour even when moving a single TButton or label on the IDE with Windows 7.
ReplyDeleteI notice that after upgrade to Windows 8 that fix was not necessary, at least moving TButtons are ok :), but I did not tried using 3D, so if it happens I see I will need to force integrated graphics (Intel).
By the way, a tech explain I read about is:
ReplyDelete"Your laptop uses a technology called Nvidia Optimus to render video output from two GPUs (the integrated Intel graphics processor, [IGP], and the more powerful Nvidia graphics card [DGPU]). This is accomplished by connecting the laptop's screen to the framebuffer of the IGP only, and allowing the DGPU to write pages of memory directly into that framebuffer. In this way, both cards can render output to the same screen, even simultaneously. When an application calls for DGPU rendering, the DGPU writes output to the portion of the screen that the application occupies. In the case of a full screen application such as a game, the DGPU will write to the entire framebuffer of the IGP"
well, but I don't understand why White is transparent while $feffffff (or $fffffffe) is white (see my other post)
ReplyDeleteMaybe a kind of bug... but "real" white (ie. clWhite) is FFFFFF and FFFFFFE is "less" white... Our eyes maybe cant see any dif, but computers do :)
ReplyDeletein fact "White" in the IDE should be $FFffffff, but it acts just like $00ffffff. I have the same bug with any color with a null alpha channel ($00ff0000, $0000ff00 ...).
ReplyDelete(haven't used FM, yet), maybe the runtime has a bug, by ignoring the alphavalue of the color, which ends up in a 32bit color value with an alpha of 0 which tells i.e. directx to fill the screen with an invisible color, which means it'll never fill the background. And maybe there are situations where it creates only a 24bit(R8G8B8) Rendertarget, where alpha is always ignored? Just wild speculations.
ReplyDeletePaul TOTH If it uses a 32Bit Rendertarget(A8R8G8B8) as default, it seems natural that a color with 0 Alpha is invisible. This tearing is what occurs when the screen is not cleared before the next drawcall and not all old pixels are overwritten by the new geometry.