Discussion:
What's about AGGPAS?
wahono sri
2012-07-31 12:16:35 UTC
Permalink
I see a good unit for 2D drawing including text drawing (true type or
freetype). http://www.crossgl.com/aggpas/
And the demo are impressive http://www.crossgl.com/aggpas/aggpas-demo.htm
And it's compatible with FPC, support win, lin and mac too.

I read Graeme implements AggPas in FPGUI, what's the result Graeme?

thanks
Ivanko B
2012-07-31 12:25:43 UTC
Permalink
Me tried its demos one day. Then it gave feeling of not using any
video hardware acceleration (even early 2D) at all thus eating CPU up
to 100% on simple demos.
Post by wahono sri
I see a good unit for 2D drawing including text drawing (true type or
freetype). http://www.crossgl.com/aggpas/
And the demo are impressive http://www.crossgl.com/aggpas/aggpas-demo.htm
And it's compatible with FPC, support win, lin and mac too.
I read Graeme implements AggPas in FPGUI, what's the result Graeme?
thanks
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
mseide-msegui-talk mailing list
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
wahono sri
2012-07-31 13:23:07 UTC
Permalink
Post by Ivanko B
Me tried its demos one day. Then it gave feeling of not using any
video hardware acceleration (even early 2D) at all thus eating CPU up
to 100% on simple demos.
I tried it from binary demo and compile from MSEide, but it look very
fast and clean, AFAIK, AggPas like vectorial drawing.
How did you test? I think if it eat up to 100% CPU, your demo has
error and looping continuesly.
Alexandre Minoshi
2012-07-31 15:52:10 UTC
Permalink
I finally recorded a video with a drawing bug

OS -archlinux
videocard - ATI Radeon HD 6310
versions:

ati-dri -8.0.4
xf86-video-ati- 1:6.14.6-1
xserver- 12.3

xfce 4.9 -4.10
mse 2.8 - latest trunk

Here link to video
http://narod.ru/disk/58587532001.59df542b2dbb31d51fd148310b834610/12345.avi.ogv.html

No problem with nvidia, intel,
No problem with vesa driver.


Yours,
Alexandre Minoshi
Graeme Geldenhuys
2012-07-31 16:03:38 UTC
Permalink
Hi,
Post by Alexandre Minoshi
I finally recorded a video with a drawing bug
Run MSEide with the -ns (no styles) parameter, and it should fix
your problem. I believe these is something you can add to your
xorg.conf file too to fix the issue too - by disabling some ATI driver
feature, but I can't remember what that is.

I have an Radeon HD 7870 with the fglrx driver and the -ns parameter,
and I don't experience that problem any more in MSEide.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
Martin Schreiber
2012-07-31 16:53:25 UTC
Permalink
Post by Alexandre Minoshi
I finally recorded a video with a drawing bug
OS -archlinux
videocard - ATI Radeon HD 6310
ati-dri -8.0.4
xf86-video-ati- 1:6.14.6-1
xserver- 12.3
xfce 4.9 -4.10
mse 2.8 - latest trunk
Here link to video
http://narod.ru/disk/58587532001.59df542b2dbb31d51fd148310b834610/12345.avi
.ogv.html
No problem with nvidia, intel,
No problem with vesa driver.
Maybe it is the radeon EXAPixmaps bug. From README.TXT:
"
Display problems with Linux radeon driver
*****************************************
If the display is distorted or slow add
Option "EXAPixmaps" "off"
to
Section "Device"
of xorg.conf, see
https://bugzilla.novell.com/show_bug.cgi?id=690766
"
If
Option "EXAPixmaps" "off"
helps, please write a bug report to the affected distribution and to x.org.

Martin
Graeme Geldenhuys
2012-07-31 14:28:15 UTC
Permalink
Post by Ivanko B
Me tried its demos one day. Then it gave feeling of not using any
video hardware acceleration (even early 2D) at all thus eating CPU up
to 100% on simple demos.
Correct, it doesn't use hardware acceleration at all. The reason you
get high CPU usage in those demos, is because most of them are very
animation intensive. Simply using the AggPas features in a standard
desktop application, will show NO CPU usage as expected.

I'm 99% sure that if I had to recreate those same demos using MSEgui
widgets (not the OpenGL ones), you will also see those high CPU
usages. That is quite normal for non-hardware accelerated 2D
frameworks.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
Martin Schreiber
2012-07-31 13:40:32 UTC
Permalink
Post by wahono sri
I see a good unit for 2D drawing including text drawing (true type or
freetype). http://www.crossgl.com/aggpas/
And the demo are impressive http://www.crossgl.com/aggpas/aggpas-demo.htm
And it's compatible with FPC, support win, lin and mac too.
Aggpas is client side pixel rendering by the CPU-> every pixel must be
transported to the graphic engine after rendering. Xlib as contrast
transports the graphic primitives only (polyline command, xcopyarea...).

Martin
wahono sri
2012-07-31 14:04:11 UTC
Permalink
Post by Martin Schreiber
Aggpas is client side pixel rendering by the CPU-> every pixel must be
transported to the graphic engine after rendering. Xlib as contrast
transports the graphic primitives only (polyline command, xcopyarea...).
Aggpas is client side pixel rendering by the CPU-> every pixel must be
transported to the graphic engine after rendering. Xlib as contrast
transports the graphic primitives only (polyline command, xcopyarea...).
I compile freetype_test.dpr with MSEide, and I got result for drawing
text performance with vary glyph rendering :

outline mode : 13.364 glyph/sec
native gray 8 : 48.781 glyph/sec
native mono :129.551 glyph/sec
AGG gray : 45.764 glyph/sec
AGG mono : 123.812 glyph/sec

I don't know if with GDI/X11
wahono sri
2012-07-31 14:15:32 UTC
Permalink
I try fpGUI with activated AggPas from MSEide, but the form is empty,
maybe any wrong in my project.

Others 2D library for Pascal is http://sourceforge.net/projects/graphics32/
Graeme Geldenhuys
2012-07-31 14:34:11 UTC
Permalink
Hi,
Post by wahono sri
I try fpGUI with activated AggPas from MSEide, but the form is empty,
maybe any wrong in my project.
I presume you used it under Windows then. I haven't finalized the
Windows bitblit implementation yet - thus the internal memory bitmap
is not painted on the form. Hence the "experimental" status. The
implementation under Linux is complete though.
Post by wahono sri
Others 2D library for Pascal is http://sourceforge.net/projects/graphics32/
There is also BGRAGraphics - see the FPC/Lazarus wiki site.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
Martin Schreiber
2012-07-31 14:45:18 UTC
Permalink
Post by wahono sri
I try fpGUI with activated AggPas from MSEide, but the form is empty,
maybe any wrong in my project.
Others 2D library for Pascal is http://sourceforge.net/projects/graphics32/
Same problem as aggpas.

Martin
Ivanko B
2012-07-31 15:34:04 UTC
Permalink
Then "Cairo" or its internal "engine" -
http://en.wikipedia.org/wiki/OpenVG (for 3D -
http://en.wikipedia.org/wiki/OpenGL_ES). They're use hardware
acceleration etc wherever possible
Post by Martin Schreiber
Post by wahono sri
I try fpGUI with activated AggPas from MSEide, but the form is empty,
maybe any wrong in my project.
Others 2D library for Pascal is
http://sourceforge.net/projects/graphics32/
Same problem as aggpas.
Martin
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
mseide-msegui-talk mailing list
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Graeme Geldenhuys
2012-07-31 15:45:18 UTC
Permalink
Post by Ivanko B
Then "Cairo" or its internal "engine" -
http://en.wikipedia.org/wiki/OpenVG (for 3D -
http://en.wikipedia.org/wiki/OpenGL_ES). They're use hardware
acceleration etc wherever possible
I think I would still choose SDL over OpenGL or OpenGL-ES. The latter
two only give you graphics, and there are so many variations of API
implementation and versions, it makes it rather hard to use (well, so
I have heard from numerous posts on the internet when I researched the
subject some months back). SDL will automatically use OpenGL, DirectX,
Quartz or Linux FrameBuffer when it is available. Also those can be
hardware accelerated, and also gives you keyboard, mouse etc input
support, and sound output support.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
Ivanko B
2012-07-31 16:07:12 UTC
Permalink
http://en.wikipedia.org/wiki/OpenVG
=======================
These allow to build fast (h/w accelerated with low CPU load & memory
bandwidth) graphics editors etc..
wahono sri
2012-07-31 16:08:54 UTC
Permalink
Post by Graeme Geldenhuys
I think I would still choose SDL over OpenGL or OpenGL-ES. The latter
two only give you graphics, and there are so many variations of API
implementation and versions, it makes it rather hard to use (well, so
I have heard from numerous posts on the internet when I researched the
subject some months back). SDL will automatically use OpenGL, DirectX,
Quartz or Linux FrameBuffer when it is available. Also those can be
hardware accelerated, and also gives you keyboard, mouse etc input
support, and sound output support.
Yes, I agree with you. SDL make simple for cross platform. But
unfortunately, we shoud wait until SDL 2.0, SDL 1.2 doesn't support
multiple windows.
Graeme Geldenhuys
2012-07-31 16:20:06 UTC
Permalink
Post by wahono sri
Yes, I agree with you. SDL make simple for cross platform. But
unfortunately, we shoud wait until SDL 2.0, SDL 1.2 doesn't support
multiple windows.
I thought MSEgui is a single handle windowing toolkit - thus only one
window handle is needed per form. (this excludes the OpenGL widget
usage of MSEgui)
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
wahono sri
2012-07-31 16:31:32 UTC
Permalink
Post by Graeme Geldenhuys
I thought MSEgui is a single handle windowing toolkit - thus only one
window handle is needed per form. (this excludes the OpenGL widget
usage of MSEgui)
Martin, is this true?
Martin Schreiber
2012-07-31 16:56:00 UTC
Permalink
Post by wahono sri
Post by Graeme Geldenhuys
I thought MSEgui is a single handle windowing toolkit - thus only one
window handle is needed per form. (this excludes the OpenGL widget
usage of MSEgui)
Martin, is this true?
MSEgui uses one handle per window (form). You write SDL supports one window
(form) per application only.

Martin
wahono sri
2012-07-31 17:27:20 UTC
Permalink
Post by Martin Schreiber
MSEgui uses one handle per window (form). You write SDL supports one window
(form) per application only.
Hmm, it should compile SDL 2.0 from source, I've compiled SDL 2.0 for
Windows and success, for Linux I think it so easy than Windows.

2nd alternative and it more simple than SDL is SFML, support multiple
windows, drawing text is suppport internally in SFML. Please see
http://www.sfml-dev.org/features.php.

And how it look simple is sample in http://sfml-dev.org/documentation/2.0/

Some GUI for C++ have created too with SFML without OpenGL (native
display for each OS) are :

http://tgui.weebly.com/index.html
http://www.sfml-dev.org/wiki/en/projects/cpgui#documentation

Using SDL or SFML without OpenGL is same as MSEgui concept at the
moment. It use native graphic rendering such as GDI (windows), X11 or
DirectFB (Linux), Cocoa (Mac), UIKit (iOS), JNI video (Android). And
for pascal binding for SDL 1.2 is ready from JEDI-SDL, I've tested it
and fully compatible.

But for SFML we should translate C header because there no pascal
binding for SFML at the moment.
Martin Schreiber
2012-07-31 17:55:59 UTC
Permalink
Post by wahono sri
Post by Martin Schreiber
MSEgui uses one handle per window (form). You write SDL supports one
window (form) per application only.
Hmm, it should compile SDL 2.0 from source, I've compiled SDL 2.0 for
Windows and success, for Linux I think it so easy than Windows.
2nd alternative and it more simple than SDL is SFML, support multiple
windows, drawing text is suppport internally in SFML. Please see
http://www.sfml-dev.org/features.php.
And how it look simple is sample in http://sfml-dev.org/documentation/2.0/
Some GUI for C++ have created too with SFML without OpenGL (native
http://tgui.weebly.com/index.html
http://www.sfml-dev.org/wiki/en/projects/cpgui#documentation
Using SDL or SFML without OpenGL is same as MSEgui concept at the
moment. It use native graphic rendering such as GDI (windows), X11 or
DirectFB (Linux), Cocoa (Mac), UIKit (iOS), JNI video (Android). And
for pascal binding for SDL 1.2 is ready from JEDI-SDL, I've tested it
and fully compatible.
But for SFML we should translate C header because there no pascal
binding for SFML at the moment.
Translating C-headers to pascal is no big problem for small libraries.

Martin
Martin Schreiber
2012-07-31 17:59:40 UTC
Permalink
Post by wahono sri
Post by Martin Schreiber
MSEgui uses one handle per window (form). You write SDL supports one
window (form) per application only.
Hmm, it should compile SDL 2.0 from source, I've compiled SDL 2.0 for
Windows and success, for Linux I think it so easy than Windows.
2nd alternative and it more simple than SDL is SFML, support multiple
windows, drawing text is suppport internally in SFML. Please see
http://www.sfml-dev.org/features.php.
And how it look simple is sample in http://sfml-dev.org/documentation/2.0/
Some GUI for C++ have created too with SFML without OpenGL (native
http://tgui.weebly.com/index.html
http://www.sfml-dev.org/wiki/en/projects/cpgui#documentation
Using SDL or SFML without OpenGL is same as MSEgui concept at the
moment. It use native graphic rendering such as GDI (windows), X11 or
DirectFB (Linux), Cocoa (Mac), UIKit (iOS), JNI video (Android). And
for pascal binding for SDL 1.2 is ready from JEDI-SDL, I've tested it
and fully compatible.
But for SFML we should translate C header because there no pascal
binding for SFML at the moment.
Outch, it s C++ not C. -> needs a flat intermediate C-interface which seems to
exist already.
"
SFML is available in the following languages :
C++
C
.Net (C#, VB.Net, C++/CLI, ...)
Python
D
Ruby
"
Martin
wahono sri
2012-07-31 18:03:44 UTC
Permalink
Post by Martin Schreiber
Outch, it s C++ not C. -> needs a flat intermediate C-interface which seems to
exist already.
"
C++
C
.Net (C#, VB.Net, C++/CLI, ...)
Python
D
Ruby
"
There is SFML package for C, please see http://sfml-dev.org/download.php
wahono sri
2012-07-31 18:05:45 UTC
Permalink
I try translate with h2pas but I got much error. I don't familiar with
C, before I use MSEgui I'm a VB6 programmer for 10 years. he he
wahono sri
2012-07-31 18:26:33 UTC
Permalink
Post by Martin Schreiber
Outch, it s C++ not C. -> needs a flat intermediate C-interface which seems to
exist already.
"
If you will try, I think SFML V2.0 RC1 is ready.

http://www.sfml-dev.org/download.php#2.0-rc
Graeme Geldenhuys
2012-07-31 17:36:47 UTC
Permalink
Post by Martin Schreiber
MSEgui uses one handle per window (form). You write SDL supports one window
(form) per application only.
Ah, ok... so SDL is meant for full-screen or single form/window apps
like games for example. Now I understand the difference. That would
also explain why eLiquid (Pixel32's GUI Toolkit) displayed all
dialogs/forms embedded (MDI style) inside the main form.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
Ivanko B
2012-07-31 17:37:57 UTC
Permalink
You write SDL supports one window
(form) per application only.
==========
Then SDL 1.x is really a game engine :)

But unfortunately, we should wait until SDL 2.0
===========
It's upcoming.
wahono sri
2012-07-31 17:38:07 UTC
Permalink
Post by Graeme Geldenhuys
Ah, ok... so SDL is meant for full-screen or single form/window apps
like games for example. Now I understand the difference. That would
also explain why eLiquid (Pixel32's GUI Toolkit) displayed all
dialogs/forms embedded (MDI style) inside the main form.
SDL 2.0 or SFML support multiple window.
wahono sri
2012-07-31 18:09:55 UTC
Permalink
Post by Graeme Geldenhuys
Ah, ok... so SDL is meant for full-screen or single form/window apps
like games for example. Now I understand the difference. That would
also explain why eLiquid (Pixel32's GUI Toolkit) displayed all
dialogs/forms embedded (MDI style) inside the main form.
And Blender use a single form for all process, it make Blender look
complicated than 3DSMax.
wahono sri
2012-07-31 16:35:52 UTC
Permalink
Post by Ivanko B
Then "Cairo" or its internal "engine" -
http://en.wikipedia.org/wiki/OpenVG (for 3D -
http://en.wikipedia.org/wiki/OpenGL_ES). They're use hardware
acceleration etc wherever possible
I used cairo for tuniversalprinter in Repaz, and it fast and can be
rendered on some target. But cairo just 2D drawing engine.
It doesn't provide input from keyboard, mouse, etc.

As I analyzed :
- Static library from C library only SDL, SFML, and Allegro that
provide drawing 2D and 3D, input handling, etc. (need some external
libraries)
- Embedded because use pascal language and provide input handling are
ZenGL and AggPas. ZenGL use OpenGL for rendering but for rendering
font is not good. It uses bitmap font and I'm sure will be run slowly
to rendering big text. If we use freetype to render text, I think it
slowly too, AFAIK rendering text in OpenGL should convert as
textures. And AggPas is client side rendering but good in drawing
concept.
Martin Schreiber
2012-07-31 17:11:00 UTC
Permalink
Post by wahono sri
Post by Ivanko B
Then "Cairo" or its internal "engine" -
http://en.wikipedia.org/wiki/OpenVG (for 3D -
http://en.wikipedia.org/wiki/OpenGL_ES). They're use hardware
acceleration etc wherever possible
I used cairo for tuniversalprinter in Repaz, and it fast and can be
rendered on some target. But cairo just 2D drawing engine.
It doesn't provide input from keyboard, mouse, etc.
- Static library from C library only SDL, SFML, and Allegro that
provide drawing 2D and 3D, input handling, etc. (need some external
libraries)
- Embedded because use pascal language and provide input handling are
ZenGL and AggPas. ZenGL use OpenGL for rendering but for rendering
font is not good. It uses bitmap font and I'm sure will be run slowly
to rendering big text. If we use freetype to render text, I think it
slowly too,
Freetype produces the glyphs only, actual text rendering is done by the
application. Please see the experimental MSEgui FreeType-OpenGL text
rendering engine in lib/common/graphics/msefontcache.pas, msefontconfig.pas,
lib/common/opengl/mseopenglgdi.pas.

Martin
wahono sri
2012-07-31 17:51:03 UTC
Permalink
Post by Martin Schreiber
Freetype produces the glyphs only, actual text rendering is done by the
application. Please see the experimental MSEgui FreeType-OpenGL text
rendering engine in lib/common/graphics/msefontcache.pas, msefontconfig.pas,
lib/common/opengl/mseopenglgdi.pas.
Currently I know about freetype. But for cross platform we should know
how to use some device such as mouse, keyboard, touch input, multi
touch input, play sound, gesturing input, etc. And I know in
MSEide+MSEgui only you as solo developer. I and maybe other just test
and make request. :)

Will you support MSEide+MSEgui in the future? For my company, we have
already produce a product build with MSEgui (234 forms and some own
component such as Repaz, etc). I think it would be serious decision to
recreate Acosys from scratch with others IDE/GUI.

If we use SFML or SDL, the complexity of hardware and others resource
of new technology in the future can be ignored, we just concentrate on
RAD and GUI and sure make money for you. :)

Our company ready to be small sponsor for this porting to all
platform, for early step we ready to appreciate you $1.000. And I hope
we can add if our product get wide market later. :)

Thanks
Martin Schreiber
2012-08-01 04:54:07 UTC
Permalink
Post by wahono sri
Post by Martin Schreiber
Freetype produces the glyphs only, actual text rendering is done by the
application. Please see the experimental MSEgui FreeType-OpenGL text
rendering engine in lib/common/graphics/msefontcache.pas,
msefontconfig.pas, lib/common/opengl/mseopenglgdi.pas.
Currently I know about freetype. But for cross platform we should know
how to use some device such as mouse, keyboard, touch input, multi
touch input, play sound, gesturing input, etc. And I know in
MSEide+MSEgui only you as solo developer. I and maybe other just test
and make request. :)
Will you support MSEide+MSEgui in the future?
Yes.
Post by wahono sri
For my company, we have
already produce a product build with MSEgui (234 forms and some own
component such as Repaz, etc). I think it would be serious decision to
recreate Acosys from scratch with others IDE/GUI.
If we use SFML or SDL, the complexity of hardware and others resource
of new technology in the future can be ignored, we just concentrate on
RAD and GUI and sure make money for you. :)
Yes, a SDL or SFML backend for MSEgui is a possibility. Although an OS X
(Quartz) backend would be more appropriate IMO. Also the OpenGL backend could
be finished. But:
On handheld devices with touch screen and gestures one can not use the widgets
which have been designed for mouse and keyboard. So one should not
underestimate the necessary expenditure to make a development tool for tablet
computers and smartphones. Implementing a backend for SFML probably is the
smallest piece of the task.
Every product has its own widgetset and controls where the user is familiar
with. So probably it is the best to use the native API's on handheld devices
with there limited resources.
On desktop computers the situation is different.

Martin
wahono sri
2012-08-01 09:10:05 UTC
Permalink
Post by Martin Schreiber
On handheld devices with touch screen and gestures one can not use the widgets
which have been designed for mouse and keyboard. So one should not
underestimate the necessary expenditure to make a development tool for tablet
computers and smartphones. Implementing a backend for SFML probably is the
smallest piece of the task.
Every product has its own widgetset and controls where the user is familiar
with. So probably it is the best to use the native API's on handheld devices
with there limited resources.
On desktop computers the situation is different.
That's the point, we can ignore about new technology in hardware if we
use 3rd party layer as SDL or SFML.
I read in their forum, most users use SDL and SFML for games
develpment and entertainment app, and they make requests about new
technology in the market. SDL implements this category in version 2,
multi touch, gesturing, etc. SFML in progress.

Some GUI platform make their GUI to be run on everywhere including
smartphone. Qt, Lazarus with custom drawn interface, Xpower++, WinDEV,
CodeName for Netbeans, and I'm sure most GUI platform would provide
new technology as multi touch input. And they use their own widget,
and I have try some demo app from them, and it's good for smartphone
and table. I think this is trend and challenge for future developer.
wahono sri
2012-08-01 11:04:36 UTC
Permalink
About programming trend in the future :
http://www.dodgycoder.net/2012/01/modern-cross-platform-development.html
wahono sri
2012-08-01 12:30:55 UTC
Permalink
Most popular OS vendor add many features for tablet and smartphone.
Windows 8 is tablet oriented, Ubuntu, Blackberry with Playback, Apple
with iOS, Android, Maemo, etc. Even native app can run on browser
(https://developers.google.com/native-client/). That's means the
future trend is operating OS with finger only, without keyboard and
mouse, everything connected through finger. And business should be
accessed anywhere, everywhere.

And the potential of MSEgui to be player in cross platform is very
possible with independent GUI, but still need backend for every OS.

I think Mainframe->PC->Notebook->Netbook->Ultrabook and Convertible
Laptop->Tablet->Smartphone is roadmap of OS until now. The number of
OS users increase from left to right.
Ivanko B
2012-08-01 13:01:18 UTC
Permalink
AFAIK all these [multi]touch*, accel* etc are translated to mouse &
keyboard & joystick events by their drivers.
wahono sri
2012-08-01 13:57:38 UTC
Permalink
Post by Ivanko B
AFAIK all these [multi]touch*, accel* etc are translated to mouse &
keyboard & joystick events by their drivers.
I try app built from MSEgui in Windows 7 tablet, and some of touching
features doen't work. In touch device, every editable text is
focusing, the virtual keyboard is visible automatically as in native
Windows app. But mse*edit* couldn't fire virtual keyboard.
Scrolling with scrollbar can be done by dragging/sliding feature.

Touch and gesturing doesn't support by SFML right now, but SDL 2.0
provide special function about gesturing
- http://wiki.libsdl.org/moin.cgi/SDL_MultiGestureEvent?highlight=%28%5CbCategoryStruct%5Cb%29%7C%28SGStructures%29%7C%28SDLStructTemplate%29)
- http://wiki.libsdl.org/moin.cgi/SDL_TouchButtonEvent?highlight=%28%5CbCategoryStruct%5Cb%29%7C%28SGStructures%29%7C%28SDLStructTemplate%29
- http://wiki.libsdl.org/moin.cgi/SDL_TouchFingerEvent?highlight=%28%5CbCategoryStruct%5Cb%29%7C%28SGStructures%29%7C%28SDLStructTemplate%29
wahono sri
2012-08-01 14:19:40 UTC
Permalink
SDL maybe focus on multimedia app and it more mature than SFML, but
SFML more simple and slim and has some feature which not belonging by
SDL, such as networking
(http://sfml-dev.org/documentation/2.0/group__network.php), create
chat app samples
https://github.com/LaurentGomila/SFML/wiki/SourceNetworkChatExample

I see some GUI built from SFML :
- http://en.sfml-dev.org/forums/index.php?topic=7023.0
- http://en.sfml-dev.org/forums/index.php?topic=6112.0
- http://en.sfml-dev.org/forums/index.php?topic=1517.0
- http://en.sfml-dev.org/forums/index.php?topic=4483.0
- http://en.sfml-dev.org/forums/index.php?topic=4048.0

And all app built from SFML in
http://en.sfml-dev.org/forums/index.php?board=10.0
Ivanko B
2012-08-01 16:48:35 UTC
Permalink
But mse*edit* couldn't fire virtual keyboard.
Scrolling with scrollbar can be done by dragging/sliding feature.
=============
It could be done by a library unit bound on widget events (focusing,
leaving,..) via regular callbacks (OnFocused,..).
Post by wahono sri
SDL maybe focus on multimedia app and it more mature than SFML, but
SFML more simple and slim and has some feature which not belonging by
SDL, such as networking
(http://sfml-dev.org/documentation/2.0/group__network.php), create
chat app samples
https://github.com/LaurentGomila/SFML/wiki/SourceNetworkChatExample
- http://en.sfml-dev.org/forums/index.php?topic=7023.0
- http://en.sfml-dev.org/forums/index.php?topic=6112.0
- http://en.sfml-dev.org/forums/index.php?topic=1517.0
- http://en.sfml-dev.org/forums/index.php?topic=4483.0
- http://en.sfml-dev.org/forums/index.php?topic=4048.0
And all app built from SFML in
http://en.sfml-dev.org/forums/index.php?board=10.0
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
mseide-msegui-talk mailing list
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Ivanko B
2012-08-01 16:51:28 UTC
Permalink
Virtual keyboard war already discussed - as a cure from key loggers :)
Post by wahono sri
But mse*edit* couldn't fire virtual keyboard.
Scrolling with scrollbar can be done by dragging/sliding feature.
=============
It could be done by a library unit bound on widget events (focusing,
leaving,..) via regular callbacks (OnFocused,..).
Post by wahono sri
SDL maybe focus on multimedia app and it more mature than SFML, but
SFML more simple and slim and has some feature which not belonging by
SDL, such as networking
(http://sfml-dev.org/documentation/2.0/group__network.php), create
chat app samples
https://github.com/LaurentGomila/SFML/wiki/SourceNetworkChatExample
- http://en.sfml-dev.org/forums/index.php?topic=7023.0
- http://en.sfml-dev.org/forums/index.php?topic=6112.0
- http://en.sfml-dev.org/forums/index.php?topic=1517.0
- http://en.sfml-dev.org/forums/index.php?topic=4483.0
- http://en.sfml-dev.org/forums/index.php?topic=4048.0
And all app built from SFML in
http://en.sfml-dev.org/forums/index.php?board=10.0
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
mseide-msegui-talk mailing list
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Ivanko B
2012-08-01 17:10:22 UTC
Permalink
than SFML, but
SFML more simple and slim
===========
Slim ? It's stated to be written in C++ which isn't slim by
definition. Then we'll also need a pure C layer over.
Ivanko B
2012-08-01 17:14:18 UTC
Permalink
http://en.sfml-dev.org/forums/index.php?topic=4048.0
==================
One more prove that C/C++ coding is masochism & heroism. Me've just
imagined coding a DB project in the used manner :)
Post by wahono sri
than SFML, but
SFML more simple and slim
===========
Slim ? It's stated to be written in C++ which isn't slim by
definition. Then we'll also need a pure C layer over.
Ivanko B
2012-08-01 17:18:25 UTC
Permalink
(http://sfml-dev.org/documentation/2.0/group__network.php)
=================
Hmm.. is it worthy? We already have excellent Pascal based Synapse
library for these purposes.
wahono sri
2012-08-01 18:02:49 UTC
Permalink
Post by Ivanko B
Slim ? It's stated to be written in C++ which isn't slim by
definition. Then we'll also need a pure C layer over.
I mean slim in implementation, because not like SDL, to drawing text
should use add-ons (3rd party lib). How it simple as in
http://sfml-dev.org/documentation/2.0/

AFAIK, C or C++ is fast because they are compild to binary as FPC. If
java compile to binary with GCJ, I think the app sould run fast too.
Java and NET run slowy because it compile again to binary when
running.
Martin Schreiber
2012-08-02 04:24:13 UTC
Permalink
Post by wahono sri
than SFML, but
SFML more simple and slim
===========
Slim ? It's stated to be written in C++ which isn't slim by
definition. Then we'll also need a pure C layer over.
That seems already available.

Martin
Ivanko B
2012-08-02 05:39:26 UTC
Permalink
That seems already available.That seems already available.
================================
Slow C++ base + fast C layer to access it [slow +
fast=slower_than_slow]. Or fast C base without any access layer
[=fast].
wahono sri
2012-08-02 12:31:03 UTC
Permalink
Post by Ivanko B
Slow C++ base + fast C layer to access it [slow +
fast=slower_than_slow]. Or fast C base without any access layer
[=fast].
Hmm, I think yes. I read at :
http://unthought.net/c++/c_vs_c++.html
http://www.cherrystonesoftware.com/doc/AlgorithmicPerformance.pdf

SDL create from C and only 1 file sdl.dll/sdl.so. For drawing text use
sdl_ttf.dll (just 2 files and freetype.dll/used by sdl_ttf). Plaform
supported win,mac,lin,ios,android.
wahono sri
2012-08-02 13:06:52 UTC
Permalink
Roadmap SDL v2 in http://wiki.libsdl.org/moin.cgi/Roadmap
Ivanko B
2012-08-02 19:01:24 UTC
Permalink
Post by wahono sri
Roadmap SDL v2 in http://wiki.libsdl.org/moin.cgi/Roadmap
AFAIK, it's already available for downloading and it should be
preffered to v1.x for choice.
wahono sri
2012-08-03 17:28:33 UTC
Permalink
Hi Martin, what's your opinion?
Ivanko B
2012-08-03 19:50:54 UTC
Permalink
SDL 1.x offers h/w acceleration for stretch/fill etc basic painting
operation. MSEgui calls the related win-32 GUI API directly and this
API is set h/w accelerated automatically by OS itself. So, v1.x don't
offer significant advantages. But v 2.x with its 3D (textures,..)
support... Me guess that the SDL backed is mostly relevant for running
on maximum number of platforms but MSEgui currently has a lot of
non-GUI code tightly bound only to the specific two platforms.
Post by wahono sri
Hi Martin, what's your opinion?
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
mseide-msegui-talk mailing list
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
wahono sri
2012-08-03 22:32:41 UTC
Permalink
About performance SDL versus SFML, there are interesting discussion in
http://en.sfml-dev.org/forums/index.php?topic=43.0.
SFML>SDL, I'm surprised!
wahono sri
2012-08-03 22:40:19 UTC
Permalink
SDL 1.2 and SDL 2.0 have different licence http://www.libsdl.org/license.php
wahono sri
2012-08-03 23:07:47 UTC
Permalink
In my laptop :

1/ Test : sprites
SDL displayed 216 frames
SFML displayed 147 frames
--> SFML is 0.7x as fast as SDL

2/ Test : alpha-blended sprites
SDL displayed 55 frames
SFML displayed 155 frames
--> SFML is 2.8x as fast as SDL

3/ Test : rotating sprites
SDL displayed 40 frames
SFML displayed 152 frames
--> SFML is 3.8x as fast as SDL

4/ Test : static text
SDL displayed 1493 frames
SFML displayed 4436 frames
--> SFML is 3.0x as fast as SDL

5/ Test : dynamic text
SDL displayed 124 frames
SFML displayed 2465 frames
--> SFML is 19.9x as fast as SDL
Ivanko B
2012-08-04 01:24:14 UTC
Permalink
SFML is 19.9x as fast as SDL
===========================
It means that SDL 1.2 (as a s/w renderer by default) don't use OpenGL
h/w accelaration in these tests (and these 20 time is surprisingly low
difference) - You should draw in OpenGL/DirectX by Yourself (SDL
provides low level API for that). SFML tries to use OpenGL/DirectX
internally whenever possible. So We just don't uderstand how to use
the low-level SDL - really only OS abstraction not everything
optimized out-of box, as its developer state.
But MSEgui can work with OpenGL (DirectX ? In win-32, It usual has far
way better drivers tah OpenGL ones). So the things look like SFML can
do the work which MSEgui can do as well that's SFML is just over
featured (too high layer) for use by MSEgui. Other side, SFML (as a
higher abstraction layer ) can detect & switch between OpenGL &
DirectX, AFAIK.

"http://www.cplusplus.com/forum/general/23944/" says :

An important detail is that SDL 1.2 doesn't normally *use* OpenGL, it
only wraps WGL/GLX/CGL so that you don't have to worry about the
details of setting up an OpenGL window on various platforms.

"http://www.archivum.info/sdl-cunTk1MwBs+***@public.gmane.org/2008-07/00387/Re-(SDL)-2-d-Accelerated-Drawing--What-are-the-options-when-using-SDL.html"
says :
So whether it's software-based or not, if you're only using SDL
primitives, Microsoft OpenGL has nothing to do with it (unless you
tweaked some stuff that had big warnings around it saying "do not use,
broken", in which case, well, it's normal if it's broken).

There's also a discussion at http://forums.tigsource.com/index.php?topic=27139.0

Also:
http://forums.libsdl.org/viewtopic.php?p=31557&sid=00998d2db2cc10d7ae7aade07f4028f0
Post by wahono sri
1/ Test : sprites
SDL displayed 216 frames
SFML displayed 147 frames
--> SFML is 0.7x as fast as SDL
2/ Test : alpha-blended sprites
SDL displayed 55 frames
SFML displayed 155 frames
--> SFML is 2.8x as fast as SDL
3/ Test : rotating sprites
SDL displayed 40 frames
SFML displayed 152 frames
--> SFML is 3.8x as fast as SDL
4/ Test : static text
SDL displayed 1493 frames
SFML displayed 4436 frames
--> SFML is 3.0x as fast as SDL
5/ Test : dynamic text
SDL displayed 124 frames
SFML displayed 2465 frames
--> SFML is 19.9x as fast as SDL
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
mseide-msegui-talk mailing list
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Ivanko B
2012-08-04 01:58:35 UTC
Permalink
http://forums.elysianshadows.com/viewtopic.php?f=6&t=4955:
--------------
Just some recommendations:

- If you are using C++ and/or want to program for PC and/or want
native use of OpenGL than go for SFML.
- If you are using C and/or want to program for embedded devices
and/or want to write software rendering stuff use SDL.

However, you should make your own decision!
------------
It's quite simple really, They are pretty much par-for-par. The only
real differences is that SFML uses OGL
where as SDL relies (generally) on software. As such, SFML is faster,
and it also supports right out the box hardware accelerated rotation +
stretching. It supports more image formats right off the bat. It also
has a simple pixel shader language based of OGL. SFML would (I expect)
use a smaller code base as SDL has more modes to support (software,
OGL, hardware render modes).

On the other hand, SFML *cannot* be run on any device that doesn't
support OGL, or any device with a very very weak graphics card. Some
people's computers have difficulty running simple popcap games for
instance.

SDL has far better OS and language support, but SFML is far more
feature rich. If I was doing a simple card game/pacman/something
simple I'd probably look at SDL for its better compatibility (Software
OR OGL modes) but otherwise, I prefer SFML.

Oh, and SFML has far better documentation (if I remember correctly)
and some decent tutorials for getting started.

K-Bal wrote:
If you are using C
SFML has a C port.
Really, there isn't much more to say. If you still can't choose, then
I suggest SFML as it's easier (IMO) to use with less road-blocks.
Post by wahono sri
SFML is 19.9x as fast as SDL
===========================
It means that SDL 1.2 (as a s/w renderer by default) don't use OpenGL
h/w accelaration in these tests (and these 20 time is surprisingly low
difference) - You should draw in OpenGL/DirectX by Yourself (SDL
provides low level API for that). SFML tries to use OpenGL/DirectX
internally whenever possible. So We just don't uderstand how to use
the low-level SDL - really only OS abstraction not everything
optimized out-of box, as its developer state.
But MSEgui can work with OpenGL (DirectX ? In win-32, It usual has far
way better drivers tah OpenGL ones). So the things look like SFML can
do the work which MSEgui can do as well that's SFML is just over
featured (too high layer) for use by MSEgui. Other side, SFML (as a
higher abstraction layer ) can detect & switch between OpenGL &
DirectX, AFAIK.
An important detail is that SDL 1.2 doesn't normally *use* OpenGL, it
only wraps WGL/GLX/CGL so that you don't have to worry about the
details of setting up an OpenGL window on various platforms.
So whether it's software-based or not, if you're only using SDL
primitives, Microsoft OpenGL has nothing to do with it (unless you
tweaked some stuff that had big warnings around it saying "do not use,
broken", in which case, well, it's normal if it's broken).
There's also a discussion at
http://forums.tigsource.com/index.php?topic=27139.0
http://forums.libsdl.org/viewtopic.php?p=31557&sid=00998d2db2cc10d7ae7aade07f4028f0
Post by wahono sri
1/ Test : sprites
SDL displayed 216 frames
SFML displayed 147 frames
--> SFML is 0.7x as fast as SDL
2/ Test : alpha-blended sprites
SDL displayed 55 frames
SFML displayed 155 frames
--> SFML is 2.8x as fast as SDL
3/ Test : rotating sprites
SDL displayed 40 frames
SFML displayed 152 frames
--> SFML is 3.8x as fast as SDL
4/ Test : static text
SDL displayed 1493 frames
SFML displayed 4436 frames
--> SFML is 3.0x as fast as SDL
5/ Test : dynamic text
SDL displayed 124 frames
SFML displayed 2465 frames
--> SFML is 19.9x as fast as SDL
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
mseide-msegui-talk mailing list
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Graeme Geldenhuys
2012-08-04 08:21:00 UTC
Permalink
Post by wahono sri
SFML is 19.9x as fast as SDL
===========================
It means that SDL 1.2 (as a s/w renderer by default) don't use OpenGL
h/w accelaration in these tests
That is how I understood it too, by reading other message threads on
the internet. You need to tell SDL when you want to use OpenGL,
DirectX etc... by default SDL will you the reference s/w renderer.
Post by wahono sri
DirectX ? In win-32, It usual has far
way better drivers than OpenGL ones.
Apparently that is not always the case. Valve Software just found out
that Linux+OpenGL actually gives much better performance for game
graphics than Windows+DirectX.

http://blogs.valvesoftware.com/linux/faster-zombies/
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
Martin Schreiber
2012-08-04 05:02:00 UTC
Permalink
Post by wahono sri
About performance SDL versus SFML, there are interesting discussion in
http://en.sfml-dev.org/forums/index.php?topic=43.0.
SFML>SDL, I'm surprised!
Hnefi:
"
Your benchmarks are severly flawed. You are comparing the software, 2D library
that ships with SDL to OpenGL. Of course you are going to get a huge
difference in performance - you don't even need to perform a benchmark to
understand that.

What would be really interesting is to see how an SDL-driven OpenGL
application performs compared to SFML. That would be a meaningful test, for
two reasons: it compares similar technologies and it benchmarks against SDL
the way SDL is almost always used.
"

Laurent:
"
It wouldn't make sense. SFML is using OpenGL, so any direct OpenGL code will
be slightly faster than SFML (unless it's really not optimized), because SFML
will always be more generic than your specific code, and genericity has a
cost (less optimizations are possible).

Basically, the main goal of using raw OpenGL over SFML is to get better
performances.
"

Jonny D:
"
[...]
I made a couple of changes and added two tests. You only tested per-surface
alpha-blending, so I added a test for per-pixel alpha (it uses SDL_image
now). You also made a couple of no-no's in the rotation and dynamic text
tests by creating surfaces within the loop (allocating and freeing tons of
memory per second). I changed the rotation test to use SGE's direct
rotations (and made it work correctly) and I plugged in NFont so that I could
cache the font, rather than generate each glyph when needed. These represent
more truly the way that people actually use SDL and its supporting libs for
speed. So, Test 2 is not very indicative of typical usage, and Test 6 should
be thrown right out. One note: Test 7 uses only Normal font style, since
NFont doesn't load the character width correctly for others.
[...]
1/ Test : sprites
SDL displayed 47 frames
SFML displayed 51 frames
--> SFML is 1.09x as fast as SDL

2/ Test : alpha-blended sprites
SDL displayed 38 frames
SFML displayed 52 frames
--> SFML is 1.37x as fast as SDL

3/ Test : per-pixel alpha-blended sprites
SDL displayed 42 frames
SFML displayed 47 frames
--> SFML is 1.12x as fast as SDL

4/ Test : rotating sprites
SDL displayed 26 frames
SFML displayed 26 frames
--> SFML is 1.00x as fast as SDL

5/ Test : static text
SDL displayed 1382 frames
SFML displayed 1023 frames
--> SFML is 0.74x as fast as SDL

6/ Test : dynamic text
SDL displayed 194 frames
SFML displayed 727 frames
--> SFML is 3.75x as fast as SDL

7/ Test : dynamic text w/NFont
SDL displayed 779 frames
SFML displayed 1113 frames
--> SFML is 1.43x as fast as SDL
"

Martin
Graeme Geldenhuys
2012-08-04 09:30:20 UTC
Permalink
Hi,
Post by Martin Schreiber
What would be really interesting is to see how an SDL-driven OpenGL
application performs compared to SFML. That would be a meaningful test, for
two reasons: it compares similar technologies and it benchmarks against SDL
the way SDL is almost always used.
I have a few commercial Linux games based on SDL. They all use
hardware acceleration - thus OpenGL under Linux. Performance is
absolutely great. Also go to YouTube and do a few SDL searches. There
are lots and lots of SDL+OpenGL backend examples that show perfectly
smooth graphics.

That SFML developer simply rigged the "benchmark tests" to promote the
SFML library - that's quite normal behaviour. SDL has been a round for
ages, has a strong developer following, and has lots of commercial
interests. SDL is even dead simple to use from Object Pascal - I use
it for cross-platform sound playback in some of our apps.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
Ivanko B
2012-08-04 09:58:30 UTC
Permalink
That SFML developer simply rigged the "benchmark tests" to promote the
SFML library
==========
Sure since how else calling same OpenGL API through C++ could be
faster than one through pure C - almost Assembler code after compiling
:)
[everyone comparing disassembler dumps of C & C++ programs will
wonder the same ]
Post by Graeme Geldenhuys
Hi,
Post by Martin Schreiber
What would be really interesting is to see how an SDL-driven OpenGL
application performs compared to SFML. That would be a meaningful test, for
two reasons: it compares similar technologies and it benchmarks against SDL
the way SDL is almost always used.
I have a few commercial Linux games based on SDL. They all use
hardware acceleration - thus OpenGL under Linux. Performance is
absolutely great. Also go to YouTube and do a few SDL searches. There
are lots and lots of SDL+OpenGL backend examples that show perfectly
smooth graphics.
That SFML developer simply rigged the "benchmark tests" to promote the
SFML library - that's quite normal behaviour. SDL has been a round for
ages, has a strong developer following, and has lots of commercial
interests. SDL is even dead simple to use from Object Pascal - I use
it for cross-platform sound playback in some of our apps.
--
Regards,
- Graeme -
_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
mseide-msegui-talk mailing list
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Ivanko B
2012-08-04 10:55:38 UTC
Permalink
MSEgui only needs polishing to run on OpenGL (so doesn't need any
SFML/SDL helping for it) .. its audio choice (PulseAudio) can run on
Linux, Win-32, Android, iOS [no need in SDL/SFML for that],.. for
networking MSEgui has the excellent Synapse [no need in SFML for
that].. correct, Martin ?
Post by Graeme Geldenhuys
That SFML developer simply rigged the "benchmark tests" to promote the
SFML library
==========
Sure since how else calling same OpenGL API through C++ could be
faster than one through pure C - almost Assembler code after compiling
:)
[everyone comparing disassembler dumps of C & C++ programs will
wonder the same ]
Post by Graeme Geldenhuys
Hi,
Post by Martin Schreiber
What would be really interesting is to see how an SDL-driven OpenGL
application performs compared to SFML. That would be a meaningful test, for
two reasons: it compares similar technologies and it benchmarks against SDL
the way SDL is almost always used.
I have a few commercial Linux games based on SDL. They all use
hardware acceleration - thus OpenGL under Linux. Performance is
absolutely great. Also go to YouTube and do a few SDL searches. There
are lots and lots of SDL+OpenGL backend examples that show perfectly
smooth graphics.
That SFML developer simply rigged the "benchmark tests" to promote the
SFML library - that's quite normal behaviour. SDL has been a round for
ages, has a strong developer following, and has lots of commercial
interests. SDL is even dead simple to use from Object Pascal - I use
it for cross-platform sound playback in some of our apps.
--
Regards,
- Graeme -
_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
mseide-msegui-talk mailing list
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Martin Schreiber
2012-08-04 11:40:25 UTC
Permalink
Post by Ivanko B
MSEgui only needs polishing to run on OpenGL (so doesn't need any
SFML/SDL helping for it) .. its audio choice (PulseAudio) can run on
Linux, Win-32, Android, iOS [no need in SDL/SFML for that],.. for
networking MSEgui has the excellent Synapse [no need in SFML for
that].. correct, Martin ?
I wrote:
"
I commented already about OpenGL. While developing the experimental MSEgui
OpenGL backend I found that it is very difficult to achieve good performance
on all the different OpenGL implementations with there different extensions,
limitations and bugs. Embarcadero for example failed with their Firemonkey
product.
"
So if SFML solves that problem especially by providing fast textdrawing and
pixmap handling on all OpenGL implementations it will be valuable. It must
ben proved first. AFAIK SDL has no high level drawing API to OpenGL, one has
to use OpenGL directly, correct?

BTW, there is a lot of copied messages again in your mail.

Martin
Ivanko B
2012-08-04 11:47:23 UTC
Permalink
AFAIK SDL has no high level drawing API to OpenGL, one has
to use OpenGL directly, correct?
===================
AFAIK, yes.


BTW, there is a lot of copied messages again in your mail.
==============
Ohh.. me forgot to switch to the advanced mode of quick answer to
erase the auto quoting. Still there's no habit to do that :)
wahono sri
2012-08-04 12:15:45 UTC
Permalink
Hi Martin, did you download benchmark test from
http://www.sfml-dev.org/temp/bench-sdl-sfml.zip, it has source and
binary for Windows, you can run it without compiling with gcc.

And you can analyze at text-dyamic.cpp, and certainly the result of
SDL & SFML. For me, SFML is very fast to draw dynamic text
Martin Schreiber
2012-08-04 12:32:09 UTC
Permalink
Post by wahono sri
Hi Martin, did you download benchmark test from
http://www.sfml-dev.org/temp/bench-sdl-sfml.zip, it has source and
binary for Windows, you can run it without compiling with gcc.
And you can analyze at text-dyamic.cpp, and certainly the result of
SDL & SFML. For me, SFML is very fast to draw dynamic text
I'll have a look later, thanks.

Martin
Ivanko B
2012-08-04 13:45:15 UTC
Permalink
For me, SFML is very fast to draw dynamic text ...
==================
SFML can outperform SDL+OpenGL only if the SFML guys have achieved
excellent algorithm optimization (caching, reusing, fine tuning,..) .
Martin Schreiber
2012-08-04 14:00:28 UTC
Permalink
Post by Ivanko B
For me, SFML is very fast to draw dynamic text ...
==================
SFML can outperform SDL+OpenGL only if the SFML guys have achieved
excellent algorithm optimization (caching, reusing, fine tuning,..) .
And it would be interesting if it is well optimized for all platforms,
especially for the embedded devices.

Martin
Ivanko B
2012-08-04 13:59:39 UTC
Permalink
http://www.sfml-dev.org/temp/bench-sdl-sfml.zip,

The result on my work machine (P4 2.4GHz, VGA Nvidia MX-440 64M AGP):

===========================================

C:\12>BenchSDL.exe
1/ Test : sprites
SDL displayed 32 frames
SFML displayed 1 frames
--> SFML is 0.0x as fast as SDL // SFML doesn't start

2/ Test : alpha-blended sprites
SDL displayed 17 frames
SFML displayed 1 frames
--> SFML is 0.1x as fast as SDL // SFML is 10 times as slower

3/ Test : rotating sprites
SDL displayed 7 frames
SFML displayed 1 frames
--> SFML is 0.1x as fast as SDL // SFML is 10 times as slower

4/ Test : static text
SDL displayed 526 frames
SFML displayed 46 frames
--> SFML is 0.1x as fast as SDL // SFML is 10 times as slower

5/ Test : dynamic text
SDL displayed 73 frames
SFML displayed 28 frames
--> SFML is 0.4x as fast as SDL // SFML is 2.5 times as slower

===========================================

So, high results of SFML may only relate to modern hardware + drivers.
Ivanko B
2012-08-04 14:10:37 UTC
Permalink
Since both SDL & SFML apps of the test start it means that OpenGL
support is present on my machine.
GLView 4.0 shows:
- version v1.1(100%) + v1.2 (12%).
- rendering test : 6fps for v1.1 & v1.2 (1.3+ are not supported)
Ivanko B
2012-08-04 14:37:38 UTC
Permalink
Hmm...these horrible timings were with M$ drivers (possible s/w
emulated OpenGL). With vedor drivers me have:

=======================
GLView 4.0 shows:
- version v1.1..1.5
- rendering test : 150..270fps
=======================

and

=======================
C:\12>BenchSDL.exe
1/ Test : sprites
SDL displayed 34 frames
SFML displayed 77 frames
--> SFML is 2.3x as fast as SDL

2/ Test : alpha-blended sprites
SDL displayed 18 frames
SFML displayed 67 frames
--> SFML is 3.7x as fast as SDL

3/ Test : rotating sprites
SDL displayed 8 frames
SFML displayed 76 frames
--> SFML is 9.5x as fast as SDL

4/ Test : static text
SDL displayed 597 frames
SFML displayed 2308 frames
--> SFML is 3.9x as fast as SDL

5/ Test : dynamic text
SDL displayed 78 frames
SFML displayed 1870 frames
--> SFML is 24.0x as fast as SDL
wahono sri
2012-08-04 15:13:23 UTC
Permalink
Post by Ivanko B
Hmm...these horrible timings were with M$ drivers (possible s/w
Ha ha ha, it's make us confusing. What's MS drivers did you use to
enable OpenGL 1.3? It's from NVidia or from MS?

I've experienced the same thing when running Blender on OpenSuse with
a driver who has not been installed, and Blender seem damaged in
appearance. I think this is the consequence of using hardware
acceleration as OpenGL.

But IMO, MSEgui is prepared to current and future programming. And
hardwares price are getting cheaper and faster development makes
people tend to replace the current hardware technology.
Graeme Geldenhuys
2012-08-04 15:38:56 UTC
Permalink
Hi,
Post by Martin Schreiber
AFAIK SDL has no high level drawing API to OpenGL, one has
to use OpenGL directly, correct?
I haven't used SDL for graphics yet, only sound. But what you said
would kind-of defeat the point of SDL. I thought SDL is a higher level
API that can talk to s/w renderer, DirectX or OpenGL. I wouldn't
expect you to hard-code OpenGL API when coding with SDL, otherwise
what is the point of SDL then.

Anyway, I also found the following Free Pascal + SDL website with lots
of information and detailed chapters on using Free Pascal with SDL. I
guess if there is any doubt as to what SDL does, maybe ask some
questions in the Pascal Game Development website.

http://www.freepascal-meets-sdl.net/

http://www.pascalgamedevelopment.com/


As for the earlier comment about SDL not supporting many image formats
and image rotation etc. Apparently the SDL-GFX add-on includes all
that.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
wahono sri
2012-08-04 16:00:58 UTC
Permalink
And bad news is SDL will follow SFML to increase speed in SDL 2.0 with
full hardware acceleration :

2. Special features in SDL 2.0 (http://wiki.libsdl.org/moin.cgi/Introduction)

Full 3D hardware acceleration
Support for OpenGL 3.0+
Support for multiple windows
Support for multiple displays
Support for multiple mice, tablets, etc.
Force Feedback available on Windows, Mac OS X and Linux

And some notes from SDL developer
(http://icculus.org/cgi-bin/finger/finger.pl?user=icculus&date=2007-10-07&section=sdl13)

- 2D acceleration: SDL can use OpenGL or Direct3D behind the scenes with
the 2D interfaces, so we can get acceleration on modern systems where
X11 or DirectDraw just aren't the fast paths anymore. The framebuffer-
oriented interfaces, like X11, are still there, though, for legacy
platforms and hardware.
- Texture support: the 2D interfaces now concern themselves with "textures"
and not surfaces. The assumption is that, even in 2D graphics, you now
want to try to push all the effort to the hardware when you can,
falling back to software where you can't. On the most basic level, this
just means you can't get at pixel-based framebuffers without locking
the "texture" and doing so may be much more expensive than in 1.2, but
in many common scenarios, a well-designed program can be significantly
more efficient in 1.3. There are some basic texture operations to offload
common per-pixel operations to hardware so you may not have to lock the
texture and do it yourself. This is meant to be a very simple API,
however: those needing more, even in 2D, should consider using OpenGL
directly.

And AFAIK, SDL 2.0 will be slowly on old hardware or not supported
driver as in SFML now.

AFAIK, currently we should focus to ease in porting MSEgui with SFML
or SDL, and I think this decision is up to Martin. SDL or SFML will be
in same way, software developer only follow vendor hardware, and when
a new hardware launch, programmers should follow it to enable new
feature.
wahono sri
2012-08-04 16:11:14 UTC
Permalink
I've experienced about this problem in before 2000, Acosys which built
from VB6 is compared with competitor that use DOS programming, they
claim their app faster than my app, but after upgrade to new PC, old
app built with DOS programming run very slow than app built from
modern programming and look like antique thing.
Ivanko B
2012-08-04 16:11:58 UTC
Permalink
Post by Ivanko B
Hmm...these horrible timings were with M$ drivers (possible s/w
Ha ha ha, it's make us confusing. What's MS drivers did you use to
enable OpenGL 1.3? It's from NVidia or from MS?
=====================
But looking in code of the text, there're no traces of OpenGL in SDL
-wriiten drawing procedures that's SDL isn't accelerated at all but
slight improvements that OS API can provide (the default for SDL). So,
the SFML team isn't 100% honest with this test. In both s/w (or
rudimentary OS) rendering for these libs, SDL is far-way faster.
Ivanko B
2012-08-04 16:13:10 UTC
Permalink
BTW, the test doesn't start on Win7 x86_64 at all.
wahono sri
2012-08-04 16:19:02 UTC
Permalink
Post by Ivanko B
BTW, the test doesn't start on Win7 x86_64 at all.
I use Win7 64 bit and it run. :)
Ivanko B
2012-08-04 16:23:54 UTC
Permalink
Me have two videocard on my home machine - the main (for primary
display) is ATI & the secondary (for game's PhisyX ) is NVidia.
Possibly the test program is buggy for running on this setup :)
Ivanko B
2012-08-04 16:48:54 UTC
Permalink
2D acceleration: SDL can use OpenGL or Direct3D behind the scenes with
the 2D interfaces, so we can get acceleration on modern systems where
X11 or DirectDraw just aren't the fast paths anymore.
========================
Expectable :) If the SFML team publishes (really) fake tests for
out-of-box configurations that the SDL team should defend oneself -
exactly by changing their out-of-box configuration.
Ivanko B
2012-08-04 16:52:07 UTC
Permalink
Most optimizations, tricks etc may be fount in :
http://www.arcsynthesis.org/gltut/
Ivanko B
2012-08-04 17:10:28 UTC
Permalink
All SDL stuff (inc subprojects) can be found at :
http://www.libsdl.org/projects/
Ivanko B
2012-08-04 17:47:33 UTC
Permalink
SDL or SFML
=========
Maybe Martin more needs to know from their code how to achieve better
optimization for the native MSEgui OpenGL backend :)
wahono sri
2012-08-04 18:15:11 UTC
Permalink
Post by wahono sri
SDL or SFML
=========
Maybe Martin more needs to know from their code how to achieve better
optimization for the native MSEgui OpenGL backend :)
If we want to use OpenGL backend, I think ZenGL is considerable
(http://zengl.org/features.html), without static linking, freepascal
lang, cross platform. We can combine or take some from ZenGL code.

But some modifications should be done are use msefreetype.pas to
combine with ZenGL. And msefontcache.pas is good for combining.

Please read :
- http://zengl.googlecode.com/svn/branches/0.3.x/src/zgl_application.pas
- http://zengl.googlecode.com/svn/branches/0.3.x/src/zgl_window.pas
- http://zengl.googlecode.com/svn/branches/0.3.x/src/zgl_primitives_2d.pas
- http://zengl.googlecode.com/svn/branches/0.3.x/src/zgl_keyboard.pas
- http://zengl.googlecode.com/svn/branches/0.3.x/src/zgl_touch.pas
- http://zengl.googlecode.com/svn/branches/0.3.x/src/zgl_joystick.pas
- http://zengl.googlecode.com/svn/branches/0.3.x/src/zgl_mouse.pas
- http://zengl.googlecode.com/svn/branches/0.3.x/src/zgl_sound.pas
- http://zengl.googlecode.com/svn/branches/0.3.x/src/zgl_video.pas
- etc.

The complexity of OpenGL compatibilities will be handled by ZenGL. :)

I've discuss with Andru, developer ZenGL in
http://zengl.org/forum/index.php/topic,332.0.html

Hi IvankoB, Andru is Russian like you.

Martin Schreiber
2012-08-04 04:43:02 UTC
Permalink
Post by wahono sri
Hi Martin, what's your opinion?
Thanks for your research, I'll studying later, much work to do at the moment.
What do you think about my comment that on smartphones and probably on other
handhelds too one should use the native widget API?

Martin
wahono sri
2012-08-04 04:59:53 UTC
Permalink
Post by Martin Schreiber
Thanks for your research, I'll studying later, much work to do at the moment.
What do you think about my comment that on smartphones and probably on other
handhelds too one should use the native widget API?
Martin
I don't agree with it, most of app especially games for iOS and
Android use some widget to change configuration, etc. and they use
custom widget (drawing).

http://www.codenameone.com/ use custom widget to iPhone/iPad (iOS),
Android, Windows Phone, Blackberry etc, and I've test it, all is OK.

I think it's MSEgui chance that it uses its own widgets into the
gadget's world. Lazarus use custom drawn interface as in
http://wiki.freepascal.org/Android_Interface
wahono sri
2012-08-04 05:10:15 UTC
Permalink
SFML has unofficial port to Android
https://github.com/Beuc/SFML-Android and for iOS
http://en.sfml-dev.org/forums/index.php?topic=951.0
wahono sri
2012-08-04 05:14:39 UTC
Permalink
Post by wahono sri
SFML has unofficial port to Android
https://github.com/Beuc/SFML-Android and for iOS
http://en.sfml-dev.org/forums/index.php?topic=951.0
While SDL for iOS and Android is officially supported.
wahono sri
2012-08-04 05:21:31 UTC
Permalink
The important widget to develope mobile app is layout container like
tlayouter in MSEgui. I see it in Qt for Android
(http://sourceforge.net/p/necessitas/home/necessitas), Android
Development Tools for Eclipse. The others widgets only button,
textbox, textmemo, slider, image, and all of them is belonging by
MSEgui now.

IMHO, you don't need care about mobile programming if using SDL/SFML.
I'm sure about it.
Ivanko B
2012-08-04 08:04:11 UTC
Permalink
What do you think about my comment that on smartphones and probably on other
handhelds too one should use the native widget API?
============
Hmm...it means that SFML doesn't suit since OpenGL is a requirement
for it. SDL provides entries for OpenGL & DirectX and s/w rendering if
these aren't supported by target platform.
Post by wahono sri
The important widget to develope mobile app is layout container like
tlayouter in MSEgui. I see it in Qt for Android
(http://sourceforge.net/p/necessitas/home/necessitas), Android
Development Tools for Eclipse. The others widgets only button,
textbox, textmemo, slider, image, and all of them is belonging by
MSEgui now.
IMHO, you don't need care about mobile programming if using SDL/SFML.
I'm sure about it.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
mseide-msegui-talk mailing list
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Martin Schreiber
2012-08-04 08:45:11 UTC
Permalink
Post by Martin Schreiber
What do you think about my comment that on smartphones and probably on
other handhelds too one should use the native widget API?
============
Hmm...it means that SFML doesn't suit since OpenGL is a requirement
for it. SDL provides entries for OpenGL & DirectX and s/w rendering if
these aren't supported by target platform.
I do not mean the rendering but actually use the native widgets of the
platform.

Martin
Ivanko B
2012-08-04 08:43:38 UTC
Permalink
mobile programming if using SDL/SFML.
=============
? Target CPU support in the platform-specific code ? Martin doesn't
even have time to adopt X86_64.
Post by Martin Schreiber
Post by Martin Schreiber
What do you think about my comment that on smartphones and probably on
other handhelds too one should use the native widget API?
============
Hmm...it means that SFML doesn't suit since OpenGL is a requirement
for it. SDL provides entries for OpenGL & DirectX and s/w rendering if
these aren't supported by target platform.
I do not mean the rendering but actually use the native widgets of the
platform.
Martin
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
mseide-msegui-talk mailing list
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Martin Schreiber
2012-08-04 09:04:23 UTC
Permalink
Post by wahono sri
mobile programming if using SDL/SFML.
=============
? Target CPU support in the platform-specific code ? Martin doesn't
even have time to adopt X86_64.
I wrote:

"
Yes, a SDL or SFML backend for MSEgui is a possibility. Although an OS X
(Quartz) backend would be more appropriate IMO. Also the OpenGL backend could
be finished. But:
On handheld devices with touch screen and gestures one can not use the widgets
which have been designed for mouse and keyboard. So one should not
underestimate the necessary expenditure to make a development tool for tablet
computers and smartphones. Implementing a backend for SFML probably is the
smallest piece of the task.
Every product has its own widgetset and controls where the user is familiar
with. So probably it is the best to use the native API's on handheld devices
with there limited resources.
On desktop computers the situation is different.
Yes, a SDL or SFML backend for MSEgui is a possibility. Although an OS X
(Quartz) backend would be more appropriate IMO. Also the OpenGL backend could
be finished. But:
On handheld devices with touch screen and gestures one can not use the widgets
which have been designed for mouse and keyboard. So one should not
underestimate the necessary expenditure to make a development tool for tablet
computers and smartphones. Implementing a backend for SFML probably is the
smallest piece of the task.
Every product has its own widgetset and controls where the user is familiar
with. So probably it is the best to use the native API's on handheld devices
with there limited resources.
On desktop computers the situation is different.

"

Martin
Martin Schreiber
2012-08-02 04:19:46 UTC
Permalink
Post by wahono sri
But mse*edit* couldn't fire virtual keyboard.
Scrolling with scrollbar can be done by dragging/sliding feature.
=============
It could be done by a library unit bound on widget events (focusing,
leaving,..) via regular callbacks (OnFocused,..).
It is planned to extend the gui_*() functions with the necessary items, for
example gui_begintextedit(), gui_endtextedit() which bind to the OS-API. For
gestures there probaby will be a gesture record which will be distributed by
twidget.mouseevent(), analogous how mousewheel events are handled now.

Martin
wahono sri
2012-08-02 14:05:44 UTC
Permalink
Post by Martin Schreiber
Freetype produces the glyphs only, actual text rendering is done by the
application. Please see the experimental MSEgui FreeType-OpenGL text
rendering engine in lib/common/graphics/msefontcache.pas, msefontconfig.pas,
lib/common/opengl/mseopenglgdi.pas.
Martin
Some consideration to use OpenGL backend
http://sjbaker.org/steve/omniv/opengl_text.html
wahono sri
2012-08-02 14:41:03 UTC
Permalink
Post by wahono sri
Some consideration to use OpenGL backend
http://sjbaker.org/steve/omniv/opengl_text.html
My conclusion (AFAIK) :

- SFML (C++) run slower than SDL (C)
- SDL more mature than SFML
- SDL support all OS since now
- SDL support all native display on all OS (GDI,X11,DiretFB,UIKit, and
JNI) and with native display is fast
- Drawing text is SDL can use msefreetype.pas (freetype library), so
we just use sdl.dll/sdl.so without sdl_ttf
- SDL only used as layer from MSEgui to OS as in
http://wiki.libsdl.org/moin.cgi/Introduction
- SDL support play audio and record audio too as in
http://icculus.org/cgi-bin/finger/finger.pl?user=icculus&date=2007-10-07&section=sdl13
- OpenGL is limit by hardware for text drawing performance, with
hardware supported GUI will be faster but if hardware not supported
will be slower than native

SDL more powerfull than others.
Martin Schreiber
2012-07-31 14:44:53 UTC
Permalink
Post by wahono sri
Post by Martin Schreiber
Aggpas is client side pixel rendering by the CPU-> every pixel must be
transported to the graphic engine after rendering. Xlib as contrast
transports the graphic primitives only (polyline command, xcopyarea...).
Aggpas is client side pixel rendering by the CPU-> every pixel must be
transported to the graphic engine after rendering. Xlib as contrast
transports the graphic primitives only (polyline command, xcopyarea...).
I compile freetype_test.dpr with MSEide, and I got result for drawing
outline mode : 13.364 glyph/sec
native gray 8 : 48.781 glyph/sec
native mono :129.551 glyph/sec
AGG gray : 45.764 glyph/sec
AGG mono : 123.812 glyph/sec
I don't know if with GDI/X11
Count the characters on MSEide source editor page and divide it by the
glyph/sec numbers and you get the time to draw a single editor page. ;-)
Did the numbers above count the transfer time from CPU memory -> graphic
server?

Martin
Graeme Geldenhuys
2012-07-31 14:20:25 UTC
Permalink
Hi,
Post by wahono sri
I read Graeme implements AggPas in FPGUI, what's the result Graeme?
I absolutely love AggPas. It is integrated into fpGUI, but is still
marked as experimental. To enable it, you simply need to specify a
compiler define, then recompile the fpGUI framework. It will then
replaces the current TfpgCanvas with an AggPas-enabled TfpgCanvas -
thus 100% backward compatible (not breaking any existing code was very
important to me). After the next fpGUI release, I'll enable AggPas as
the default Canvas class, and then build in support for the more
advanced AggPas features.

Here is a screenshot of one of my existing canvas demos, that I
extended with AggPas features.

Loading Image...

Some features demo'd in that screenshot:
* dashed lines generator
* outlined shapes
* custom stare shape generator
* gradient fills (to left, right, top, bottom and any angle inbetween)
* rotated anti-aliased text
* different TTF fonts used
* sub-pixel anti-aliased line drawing showing 0.2 pixel width lines
to 10+ pixels width
* arc drawing
* different line end-caps & line connecting methods
* alpha blending support
* co-ordinate transformation & rotation

AggPas is a vector based drawing library, all features are implemented
in 100% Object Pascal code, so you get consistent look and features on
all platforms you run it on. It really is a brilliant piece of work.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
wahono sri
2012-07-31 18:12:26 UTC
Permalink
Post by Graeme Geldenhuys
I absolutely love AggPas. It is integrated into fpGUI, but is still
marked as experimental. To enable it, you simply need to specify a
compiler define, then recompile the fpGUI framework. It will then
replaces the current TfpgCanvas with an AggPas-enabled TfpgCanvas -
thus 100% backward compatible (not breaking any existing code was very
important to me). After the next fpGUI release, I'll enable AggPas as
the default Canvas class, and then build in support for the more
advanced AggPas features.
I see in your code of fpGUI is separated between GUI and OS, I'm sure
it isn't complicated to port to others platform.
Graeme Geldenhuys
2012-07-31 22:22:47 UTC
Permalink
Hi,
Post by wahono sri
I see in your code of fpGUI is separated between GUI and OS, I'm sure
it isn't complicated to port to others platform.
Correct, I tread AggPas almost as if it is another backend - similar
to GDI or X11. I still had to keep the GDI and X11 functionality
though, for window handling, user input etc. All painting is offloaded
to AggPas, which generates a memory bitmap from the vector data, then
I simply bit blit it to the window.

Integrating it with other GUI toolkits shouldn't be too hard - though
I only know fpGUI internals well. One thing to take note of though...
AggPas (or really AGG) was designed to be procedure based, where you
can string any set of procedures together to generate the output you
desire. This is immensely powerful! I opted to scale that back a bit,
and rather use a TAggPas class that does everything I need. This
slightly limits the true power of AggPas, but it is still more than
enough to accomplish awesome painting, and much easier to work with.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
Loading...