On Wed, Oct 12, 2011 at 6:23 PM, Christian Nilsson <nik...@gmail.com> wrote:
> Yes, Tested and everything is drawn and invalidated as I expect it to be. > nice changes, Thanks! > awesome :) > 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. > I'll test it out, libfreerdp-gdi's implementation will basically be equivalent to the one for Windows (libfreerdp-gdi matches GDI). The original data in the polyline order matches GDI's Polyline() anyway: http://msdn.microsoft.com/en-us/library/dd162815(v=vs.85).aspx I think all that is needed is a call to MoveTo() before Polyline() > > 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
