Yes, Tested and everything is drawn and invalidated as I expect it to be. nice changes, Thanks! Something to look at some time is also the --gdi sw implementation if it should work, I have good testcases for this now if its needs testing.
On Thu, Oct 13, 2011 at 12:12 AM, Marc-André Moreau <marcandre.mor...@gmail.com> wrote: > Hi Christian, > Just pushed an updated version of the polyline parsing and rendering. The > most portable way to do it is to simply not transform the original data. Let > me know if it fixes the problem. > > On Wed, Oct 12, 2011 at 5:38 PM, Christian Nilsson <nik...@gmail.com> wrote: >> >> Ah yes, never looked on how the data came in, only thought the problem >> was in the drawing ;) >> the most portable way is the best - what calls is available and will >> be used in the windows client? >> >> On Wed, Oct 12, 2011 at 11:23 PM, Marc-André Moreau >> <marcandre.mor...@gmail.com> wrote: >> > Reading more about XDrawLines, I think I understand more: >> > http://tronche.com/gui/x/xlib/graphics/drawing/XDrawLines.html >> > The current polyline parsing code is converting between relative to >> > absolute >> > coordinates for each point. The original data is given as a first point >> > in >> > absolute coordinates followed by an array of points relative to each >> > other. >> > The number of points is the number of points in that array, but in total >> > there is one point more if we include the first one which is not >> > included in >> > the array. The current code is probably missing one point. >> > I could modify the orders parsing to put the first point in absolute >> > coordinates as the first element of the point array, followed by the >> > point >> > array in relative coordinates to the previous point. Converting that >> > array >> > to an array of XPoints and passing it to XDrawLines along with >> > CoordModePrevious should then behave properly. >> > >> > On Wed, Oct 12, 2011 at 5:04 PM, Christian Nilsson <nik...@gmail.com> >> > wrote: >> >> >> >> Ok i think i understand how invalidate works now, and it did not have >> >> anything to do with the display problem. >> >> Thanks Marc-André for giving me the push to mangle this out. >> >> >> >> Found that the polygon was never closed. Maybe there is some better X >> >> call to do this? >> >> >> >> For reference I attached images how the memory bar is drawn in taskmgr >> >> with the different modes. (color forced to red in code) >> >> with CoordModePrevious we get a diagonal line. >> >> with CoordModeOrigin we get a U, the top line is not drawn, but it >> >> looks more correct. >> >> >> >> and then we have the patch this is mostly for debugging. but what it >> >> also does is to draw the last line of the poly, back to the start >> >> point. >> >> This gives the last image CoordModeOrigin_ExtraPoint. >> >> removing the forced red color now draws the new message window in >> >> Outlook correctly for me. >> >> >> >> >> >> I noted that it works with just >> >> points = xmalloc(sizeof(XPoint) * polyline->numPoints); >> >> No extra +1 for the counter, I'm not sure witch are most correct? >> >> >> >> >> >> >> >> On Wed, Oct 12, 2011 at 10:05 PM, Marc-André Moreau >> >> <marcandre.mor...@gmail.com> wrote: >> >> > 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
