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
