http://bugs.winehq.org/show_bug.cgi?id=58921 --- Comment #17 from Giang Ng <nen24t@gmail.com> --- Thanks for the precise re-measurement in comment 16: the single red pixel at the top-left pointed straight at the cause. The observations for a child created directly in the layered top-level (blue; with the child covering the whole window, red only at the top-left pixel; red with a plain window in between) reproduce with an application-free probe of that layout when the target window's class has CS_PARENTDC and the window has neither WS_CLIPSIBLINGS nor WS_CLIPCHILDREN. Without CS_PARENTDC, or with WS_CLIPSIBLINGS added, the same layout was red on d2d1-dcomp-11.19 before the change below. For such a window GetDC() uses DCX_PARENTCLIP, and that branch of get_visible_region() (server/window.c) starts from the parent's client rect intersected with the parent's surface rect, which for an UpdateLayeredWindow() top-level is the one-pixel rect. 6d09e40424a (c3c3d74a571 on d2d1-dcomp-11.19) exempted only the ancestor loop further down from that rect, not this branch. With a plain window in between, the parent clip is taken from that window instead. Fixed in https://github.com/giang17/wine/commit/4654170ab03 (branch d2d1-dcomp-11.0; on d2d1-dcomp-11.19 as e7a6a9fc572). With CS_PARENTDC on the target class: blue in 8 of 8 child style and content combinations before (d2d1-dcomp-11.19), red in 8 of 8 after on both branches; a child covering part of the window is red on exactly its own area. On the Windows side, which comment 16 left open: Windows 10 shows the tree of a WS_EX_NOREDIRECTIONBITMAP child of a second process over an UpdateLayeredWindow() top-level, with and without CS_PARENTDC on the child's class. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.