On 03/23/2011 03:22 PM, Vic Lee wrote:
> On 03/23/2011 10:16 PM, Mads Kiilerich wrote:
>> Ok. Can you share some thoughts if don't plan to look into this?
>>
>> Do you have any idea what the problem could be? What did you try that
>> didn't work?
>
> I tried to review the whole drawing program bit
On Thu, Mar 24, 2011 at 11:11 AM, Otavio Salvador
wrote:
> Hello Marc-Andre,
>
> I agree with most of this concept except that I think xfreerdp
> shouldn't implement the X11 GDI calls but those ought to be provided
> by a libfreerdpgdi X11 backend. So if we implement a new client we
> won't need t
Hello Marc-Andre,
I agree with most of this concept except that I think xfreerdp
shouldn't implement the X11 GDI calls but those ought to be provided
by a libfreerdpgdi X11 backend. So if we implement a new client we
won't need to redo all this again.
--
Otavio Salvador
Overall, I definitely think having a common rendering library is a great step
forward, and will help reduce code duplication and get Freerdp onto more
platforms.
FFMpeg's libswscale would be a possible option for color conversion, they have
assembly code for various platforms.
I'm a little sk
On Wed, Mar 23, 2011 at 23:53, Marc-André Moreau
wrote:
...
> @otavio: I know your concerns regarding performance, and I share them with
> you. Don't worry, we won't ditch the current code for something less
> performant, unless we actually make it fast enough to match the current
> performance or
Some of the most expensive operations are color conversion and "SRCCOPY"
bitblts, because they involve copying large pixel buffers.
Color conversion - including in xfreerdp and wfreerdp - is currently not
hardware accelerated at all. For this part of libfreerdpgdi, we could start
adapting all of o
I had some attempt to implement the drawing on cairo, which is
cross-platform and hardware-accelerated. But unfortunately I cannot
finish it because cairo does not support any kind of bitwise operation,
which is crucial in RDP drawing (ROP2, ROP3). Maybe EGL is also an option?
On 03/24/2011 05:
On Wed, Mar 23, 2011 at 18:20, Marc-André Moreau
wrote:
> There is at least one part of libfreerdpgdi that could be used everywhere:
> gdi_color.c
> The color conversion is currently done in software, and probably eats half
> of the CPU usage related to GDI. We just need to add cursor support for
There is at least one part of libfreerdpgdi that could be used everywhere:
gdi_color.c
The color conversion is currently done in software, and probably eats half
of the CPU usage related to GDI. We just need to add cursor support for it.
We're looking on ways to add GPU acceleration to libfreerdp
On Wed, Mar 23, 2011 at 14:58, Jay Sorg wrote:
...
> When I was looking at our new wfreerdp, it looks like it's win32 only.
> If that is the case, it can be greatly optimized and the drawing
> issues fixed.
> If the goal is to be win32/wince compatible, we should use libfreerdpgdi.
My main conce
> This is were I fear about the layer. I do like the idea and think this
> is the way to go but from our tests here FreeRDP is slower then
> RDesktop in some cases and seems to be related to our "indirection"
> layer. Adding GDI above it could make it worse.
Yea, bsops.c later libfreerdpgdi was in
On Wed, Mar 23, 2011 at 12:42, Vic Lee wrote:
> Yes I agree a common drawing library libfreerdpgdi will be awesome. Will
> it be as fast as using X11 or Windows API drawing?
This is were I fear about the layer. I do like the idea and think this
is the way to go but from our tests here FreeRDP is
Hi Marc,
Yes I agree a common drawing library libfreerdpgdi will be awesome. Will
it be as fast as using X11 or Windows API drawing?
Vic
On 03/23/2011 11:04 PM, Marc-André Moreau wrote:
> Hi Vic,
>
> I think on the long term the best solution would be to work on improving
> libfreerdpgdi so tha
Hi Vic,
I think on the long term the best solution would be to work on improving
libfreerdpgdi so that it can be used everywhere. I've been working with
thinstuff lately on making it "pixel perfect". We'd like to start a branch
soon for an experimental version of xfreerdp that would use libfreerdp
On 03/23/2011 10:16 PM, Mads Kiilerich wrote:
> Ok. Can you share some thoughts if don't plan to look into this?
>
> Do you have any idea what the problem could be? What did you try that
> didn't work?
I tried to review the whole drawing program bit by bit but unfortunately
I couldn't find any cl
Ok. Can you share some thoughts if don't plan to look into this?
Do you have any idea what the problem could be? What did you try that
didn't work?
/Mads
On 03/23/2011 03:03 PM, Vic Lee wrote:
> Actually I did saw some artifact, but I couldn't figure it out when I
> wrote it.
>
> On 03/23/201
Actually I did saw some artifact, but I couldn't figure it out when I
wrote it.
On 03/23/2011 06:44 PM, Mads Kiilerich wrote:
> I noticed some redraw problems with wfreerdp - xfreerdp works fine.
> Connecting to 2003 or 2008.
>
> When the remote Task Manager performance graph is shown there are o
I noticed some redraw problems with wfreerdp - xfreerdp works fine.
Connecting to 2003 or 2008.
When the remote Task Manager performance graph is shown there are often
two artifacts:
wfreerdp shows an extra 1 pixel white border around the CPU Usage and
Memory meters, and sometimes the border h
18 matches
Mail list logo
