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
