I just pushed an improvement for the region invalidation as for CoordModeOrigin, I'll have to look into it
On Wed, Oct 12, 2011 at 3:34 PM, Marc-André Moreau < marcandre.mor...@gmail.com> wrote: > > > On Wed, Oct 12, 2011 at 3:25 PM, Christian Nilsson <nik...@gmail.com>wrote: > >> Hi >> >> When writing new messages in Outlook 2010 I get some graphical problems... >> I have not found anything else that uses this? or at least where the >> problem is visible in the same way. (taskmgr uses it but draws black >> lines on black background) >> >> What I've detected so far. (or at least i think) >> all this is in function xf_gdi_polyline >> >> * CoordModePrevious needs to be changed to CoordModeOrigin, Otherwise >> it draws diagonally. >> * needs a fix for the last (or first) line of gdi_InvalidateRegion, >> and this i'm not sure on how it should be done. >> >> This can quite easily be seen if forcing the color to something easy >> to see, i used color = 0xff0000; >> With these changes i now have a "U" in taskmgr and the same in >> Outlook, now just the top line needs to be invalidated. >> >> Another thing i noted when poking around: this function always calls >> gdi_InvalidateRegion while most other functions only do so if >> (xfi->drawing == xfi->primary) >> and some even inside if (xfi->remote_app != True) >> does it mater? why the inconsistency of gdi_InvalidateRegion? >> > > that's actually a bug, I should look into it. > > gdi_InvalidateRegion is used to invalidate a region on the primary surface. > When in desktop mode, the drawing operation is performed twice on the > primary buffer and on the actual window buffer. When in RemoteApp mode, the > region is invalidated on the primary buffer, and the invalidated region is > only copied to the corresponding windows when EndPaint is being called. > > if (xfi->drawing == xfi->primary) checks that the operation is performed on > the primary buffer (we only invalidate on the primary buffer) > > if (xfi->remote_app != True) checks that we're in desktop mode, and > performs the same graphical operation on the window buffer as wall. this > cannot be done in RemoteApp mode due to the fact that there are multiple > windows instead of one that corresponds 1:1 to the primary buffer. > > In both cases, we want to invalidate the region on the primary buffer. In > desktop mode, this information is discarded, but in RemoteApp it is used on > the call to EndPaint. > > Performing the same operation twice on the primary buffer and the window > buffer in desktop mode is faster in many cases. For instance, line drawing > is faster when done twice instead of done once on the primary buffer, and > then copying the invalidated area from the primary buffer to the window > buffer. > >> >> cmd for testing, just in case it has anything to do with it. >> client/X11/xfreerdp -u Christian -g 2800x1024 -x $((128+256)) -a 32 >> winbox.local >> >> /Christian >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2d-oct >> _______________________________________________ >> Freerdp-devel mailing list >> Freerdp-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freerdp-devel >> > > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
