Leigh's GUI [OT]

[Paul]

Hello
Leigh are you sure there is a market/requirement amongst Android developers
for your C++ graphics thingy, re: http://neogfx.org

I was looking at developing for Android it seems all applications run in a
JVM. Sure native code can be used but this would be through JNI so I don't
see how your neogfx program would work on an android system.



--- Posted via news://freenews.netfront.net/ - Complaints to ne...@netfront.net ---

[Leigh Johnston]

On 27/01/2012 22:23, Paul <pchrist wrote:
> Hello
> Leigh are you sure there is a market/requirement amongst Android developers
> for your C++ graphics thingy, re: http://neogfx.org
>
> I was looking at developing for Android it seems all applications run in a
> JVM. Sure native code can be used but this would be through JNI so I don't
> see how your neogfx program would work on an android system.

That is off-topic, yes.

/Leigh

[Paul]

"Leigh Johnston" <le...@i42.co.uk> wrote in message
news:WPOdnaY3rJP0uL7S...@giganews.com...

Well I thought it may make an interesting discussion since there isn't much
else going on around here.

The android OS has become quite a big player in the booming smartphone
sector. I think most C++ programmers would be interested in what the C++
languages' role is in this OS.
AFAICT there is not a not much support for C++ at application level , other
than through JNI. It would be interesting to see how C++ is being used in
lower level devopment with this OS.

Anyways regards the neogfx thing , I don't see why you have chosen to make
this GUI library compatable with two incompatable OS's. If you were
targetting windows(CE) and android , I could see a connection. Anyways there
is already a Graphics library on both windows and android and that is OpenGL
but on android OpenGL is exposed as a Java interface as opposed to windows
where it's exposed as a C++ API.

[Leigh Johnston]

On 28/01/2012 00:09, Paul <pchrist wrote:
> "Leigh Johnston"<le...@i42.co.uk> wrote in message
> news:WPOdnaY3rJP0uL7S...@giganews.com...
>> On 27/01/2012 22:23, Paul<pchrist wrote:
>>> Hello
>>> Leigh are you sure there is a market/requirement amongst Android
>>> developers
>>> for your C++ graphics thingy, re: http://neogfx.org
>>>
>>> I was looking at developing for Android it seems all applications run in
>>> a
>>> JVM. Sure native code can be used but this would be through JNI so I
>>> don't
>>> see how your neogfx program would work on an android system.
>>
>> That is off-topic, yes.
>>
>
> Well I thought it may make an interesting discussion since there isn't much
> else going on around here.
>
> The android OS has become quite a big player in the booming smartphone
> sector. I think most C++ programmers would be interested in what the C++
> languages' role is in this OS.
> AFAICT there is not a not much support for C++ at application level , other
> than through JNI. It would be interesting to see how C++ is being used in
> lower level devopment with this OS.

You have obviously not done much research; see "Necessitas" (Qt for
Android).

>
> Anyways regards the neogfx thing , I don't see why you have chosen to make
> this GUI library compatable with two incompatable OS's. If you were

The whole point of a cross-platfrom library is to support multiple
incompatible operating systems.

> targetting windows(CE) and android , I could see a connection. Anyways there
> is already a Graphics library on both windows and android and that is OpenGL
> but on android OpenGL is exposed as a Java interface as opposed to windows
> where it's exposed as a C++ API.

A GUI library is not a graphics library.

/Leigh

[Paul]

"Leigh Johnston" <le...@i42.co.uk> wrote in message

news:CqSdnWPV0446bL7S...@giganews.com...

Qt applications on android are Java applications that run in VM. They use
JNI to access native code, see the NDK link at end of this post.

>>
>> Anyways regards the neogfx thing , I don't see why you have chosen to
>> make
>> this GUI library compatable with two incompatable OS's. If you were
>
> The whole point of a cross-platfrom library is to support multiple
> incompatible operating systems.
>

But a Graphical User Interface library that is suitable for small
touchscreen phones would not have the same features as for a PC.

>> targetting windows(CE) and android , I could see a connection. Anyways
>> there
>> is already a Graphics library on both windows and android and that is
>> OpenGL
>> but on android OpenGL is exposed as a Java interface as opposed to
>> windows
>> where it's exposed as a C++ API.
>
> A GUI library is not a graphics library.
>

Android already has a good GUI library and its very easy to implement using
simple XML see:
http://developer.android.com/guide/topics/ui/index.html


The only support for C++( or C99) I can find is renderscript:
http://developer.android.com/guide/topics/renderscript/index.html

and via the NDK ref:
http://developer.android.com/sdk/ndk/overview.html

[Leigh Johnston]

You obviously do not know what Qt is: Qt is a C++ GUI library not a Java
GUI library. How an Android Qt application runs and how it is split
between native and JVM parts is an implementation detail of the library
itself and that should not have any direct bearing on the C++ Qt
application.

>
>>>
>>> Anyways regards the neogfx thing , I don't see why you have chosen to
>>> make
>>> this GUI library compatable with two incompatable OS's. If you were
>>
>> The whole point of a cross-platfrom library is to support multiple
>> incompatible operating systems.
>>
> But a Graphical User Interface library that is suitable for small
> touchscreen phones would not have the same features as for a PC.

Nonsense; a tablet is not that much different to a laptop with regards
to screen size. The majority of an application's implementation should
be common to all platforms and other parts can be tailored to the target
platform. My library allows widget dimensions to be specified in inches
rather than pixels for example to facilitate device agnostic design.

>>> targetting windows(CE) and android , I could see a connection. Anyways
>>> there
>>> is already a Graphics library on both windows and android and that is
>>> OpenGL
>>> but on android OpenGL is exposed as a Java interface as opposed to
>>> windows
>>> where it's exposed as a C++ API.
>>
>> A GUI library is not a graphics library.
>>
> Android already has a good GUI library and its very easy to implement using
> simple XML see:
> http://developer.android.com/guide/topics/ui/index.html

It should be obvious that I am not interested in Java Android App
development.

/Leigh

[Paul]

"Leigh Johnston" <le...@i42.co.uk> wrote in message

news:PtmdnaIGhqdBvLnS...@giganews.com...

A GUI designed for a touchscreen device will be alot different from a GUI
designed for a PC with standard mouse/keyboard input.

[Leigh Johnston]

On 28/01/2012 16:37, Paul <pchrist wrote:
> "Leigh Johnston"<le...@i42.co.uk> wrote in message
> news:PtmdnaIGhqdBvLnS...@giganews.com...
>> On 28/01/2012 15:26, Paul<pchrist wrote:
>>> "Leigh Johnston"<le...@i42.co.uk> wrote in message
>>> news:CqSdnWPV0446bL7S...@giganews.com...
>>>> On 28/01/2012 00:09, Paul<pchrist wrote:

[snip]

>>>>> Anyways regards the neogfx thing , I don't see why you have chosen to
>>>>> make
>>>>> this GUI library compatable with two incompatable OS's. If you were
>>>>
>>>> The whole point of a cross-platfrom library is to support multiple
>>>> incompatible operating systems.
>>>>
>>> But a Graphical User Interface library that is suitable for small
>>> touchscreen phones would not have the same features as for a PC.
>>
>> Nonsense; a tablet is not that much different to a laptop with regards to
>> screen size. The majority of an application's implementation should be
>> common to all platforms and other parts can be tailored to the target
>> platform. My library allows widget dimensions to be specified in inches
>> rather than pixels for example to facilitate device agnostic design.
>>
>
> A GUI designed for a touchscreen device will be alot different from a GUI
> designed for a PC with standard mouse/keyboard input.

Untrue; a GUI designed for a touchscreen device can be quite similar to
a GUI designed for a PC and in fact Windows 8 allows for both
touchscreen and a keyboard/mouse. There is no reason why an individual
widget cannot work on both touchscreen devices and keyboard/mouse
devices; what is more likely to differ is not widget code but layout code.

/Leigh

[88888 Dihedral]

在 2012年1月29日星期日UTC+8上午12时37分36秒，Paul写道：

> "Leigh Johnston" <le...@i42.co.uk> wrote in message
> news:PtmdnaIGhqdBvLnS...@giganews.com...
> > On 28/01/2012 15:26, Paul

> > "Leigh Johnston"<le...@i42.co.uk> wrote in message
> >> news:CqSdnWPV0446bL7S...@giganews.com...
> >>> On 28/01/2012 00:09, Paul

> >>> "Leigh Johnston"<le...@i42.co.uk> wrote in message
> >>>> news:WPOdnaY3rJP0uL7S...@giganews.com...
> >>>>> On 27/01/2012 22:23, Paul

The touch screen part is just another event generator hooked to the OS at all.
I don't agree that the a well designed GUI library or package would be
limited by the OS. The user interface part is not time critical in most
message handling and dispatching jobs to call the part that really does the heavy computing works.

[88888 Dihedral]

在 2012年1月28日星期六UTC+8上午8时09分22秒，Paul写道：

> "Leigh Johnston" <le...@i42.co.uk> wrote in message
> news:WPOdnaY3rJP0uL7S...@giganews.com...
> > On 27/01/2012 22:23, Paul

Don't be fool by Apple's consumer ready to use techie toys at all.
The roadmap is WIMAX to LTE before 2020 to relpace the cheap old GSM.
In this part C++ is not very useful for those DSP routines in mobile systems.

[Paul]

"88888 Dihedral" <dihedr...@googlemail.com> wrote in message
news:5242308.346.1327783959182.JavaMail.geo-discussion-forums@prez15...
? 2012?1?29????UTC+8??12?37?36?,Paul??:

--The touch screen part is just another event generator hooked to the OS at
all.
--I don't agree that the a well designed GUI library or package would be
--limited by the OS. The user interface part is not time critical in most
--message handling and dispatching jobs to call the part that really does
the heavy computing works.


GUI design is a branch of computer design/engineering in itself and I'm sure
if you were to consult a GUI design expert you would be advised that
smartphones and PC's are not comptable when it comes to GUI design.
This is the reason I query leigh's target market/users. I feel that android
developers and windows PC developers do not share a common GUI design
objective. The GUI for a windows PC software program is never (or very
rarely) going to be the same as that of a smartphone or android device.

[Ian Collins]

On 01/29/12 10:35 AM, 88888 Dihedral wrote:

> The roadmap is WIMAX to LTE before 2020 to relpace the cheap old GSM.
> In this part C++ is not very useful for those DSP routines in mobile systems.

The last mobile DSP project I was involved in used C++.

--
Ian Collins

[88888 Dihedral]

在 2012年1月29日星期日UTC+8上午6时29分10秒，Ian Collins写道：

I'll use pointers to structures for any heavy computing jobs in DSP
in the C way.

Even the v-pointer to the v-table for each element in 2D or 3D are
slowingdown the process.

Of course a lot people don't do digtal image or video processing for
a window convolution larger than 16X16.

Just implement a Wiener filter of a simple model for an image of a high priced
digital camcorder for hand shakinking elimanation of motion blurred sources,
then the C++ funny way is not very useful at all.

[Ian Collins]

On 01/29/12 11:46 AM, 88888 Dihedral wrote:
> 在 2012年1月29日星期日UTC+8上午6时29分10秒，Ian Collins写道：
>> On 01/29/12 10:35 AM, 88888 Dihedral wrote:
>>
>>> The roadmap is WIMAX to LTE before 2020 to relpace the cheap old GSM.
>>> In this part C++ is not very useful for those DSP routines in mobile systems.
>>
>> The last mobile DSP project I was involved in used C++.

Please don't quote signatures

> I'll use pointers to structures for any heavy computing jobs in DSP
> in the C way.
>
> Even the v-pointer to the v-table for each element in 2D or 3D are
> slowingdown the process.
>
> Of course a lot people don't do digtal image or video processing for
> a window convolution larger than 16X16.

Even more people don't do any video processing. DSPs have many uses.

> Just implement a Wiener filter of a simple model for an image of a high priced
> digital camcorder for hand shakinking elimanation of motion blurred sources,
> then the C++ funny way is not very useful at all.

What "C++ funny way"? There are as many ways to use C++ as there are
problems to solve.

--
Ian Collins

[88888 Dihedral]

在 2012年1月29日星期日UTC+8上午7时28分39秒，Ian Collins写道：

I'll make my point clear in heavy computing tasks. It is better to program
in registers directly supported in hardware operations without any extra-
overhead in the basic operations.

Higher level languages that will introduce any overhead in basic operations are not very helpful in this situation.

[88888 Dihedral]

在 2012年1月29日星期日UTC+8上午6时29分10秒，Ian Collins写道：

In my experiments of implementing arithmetics in different fields or rings
for DSP algorithms, the operator reloading in C++ actually will slow down basic operations.

[hanukas]

On Jan 29, 12:46 am, 88888 Dihedral <dihedral88...@googlemail.com>
wrote:

> 在 2012年1月29日星期日UTC+8上午6时29分10秒，Ian Collins写道：
>
> > On 01/29/12 10:35 AM, 88888 Dihedral wrote:
>
> > > The roadmap is WIMAX to LTE before 2020 to relpace the cheap old  GSM.
> > > In this part C++ is not very useful for those DSP routines in mobile systems.
>
> > The last mobile DSP project I was involved in used C++.
>
> > --
> > Ian Collins
>
> I'll use  pointers to  structures for any heavy computing jobs in DSP
> in the C way.
>
> Even the v-pointer to the v-table for each element in 2D or 3D are
> slowingdown the process.

Of course. Same can be said about redundant computation, for example:

process_sample(x, y, ..);
-->
*(address + offset)
++offset
-->
~= address[offset++]

- avoid unnecessary method/function calls

- don't compute stride*y for each sample, you KNOW the address of next
sample when process samples in predictable order

- if you process samples in predictable order, you can also predict
the access pattern from cache's point of view; for 2D data, tile it
for better local coherency and minimize cache misses

- can you reduce ALU cost with data-level parallelism?

- can you reduce overhead with process level parallelism?

.. and other interesting architectural decisions that you can make. C/C
++ is irrelevant argument when the programmer is proficient. The C++
constructs allow more readable code with no performance impact. No one
is suggesting you need to invoke virtual c++ method call for each
processed sample, except you.. why are you using that as argument
against C++ if you are a very good programmer?

> Of course a lot people don't do digtal image or video processing for
> a window convolution larger than 16X16.

I do something where we have to process over 100,000,000 samples per
second, 1-2 million samples at 60 fps. It's called real-time
rendering. And we have to do that with only few watts, there isn't
much room to waste power on redundant computation.

> Just implement a Wiener filter of a simple model for an image of a high priced
> digital camcorder for hand shakinking elimanation of motion blurred sources,
> then the C++ funny way is not very useful at all.

The C++ funny way, whatever it is that you mean by that probably
isn't. But there is nothing in C (!) that it could do better. It comes
down to knowing what you are doing, sounds to me that you only know
how to write poorly performing C++ code so I would say that you're not
the best possible go-to guy for advice. No offence, it just comes out
that way.

[88888 Dihedral]

在 2012年1月30日星期一UTC+8下午4时55分39秒，hanukas写道：
> On Jan 29, 12:46 am, 88888 Dihedral <dihedr...@googlemail.com>

What I have emphasized is that C++ is better in a high level of controls
of complex components organized as easy to use objects in a library or a package to be used by others, but it should not be
used for heavy computing in the low level that needs to deal with hardware
to avoid unnecessary overheads in repeated basic operations.

[hanukas]

On Jan 30, 8:46 pm, 88888 Dihedral <dihedral88...@googlemail.com>
wrote:

For dealing with hardware there are two primary choices which are
preferred:

1. GPU: CUDA, OpenCL, OpenGL/GLSL, D3D/HLSL, Cg, etc.
2. CPU: SIMD/MT -JIT

The (1) is self-explatonary. The less often taken path is the (2),
which is very expensive to implement as in worst case it is task
comparable to writing optimizing compiler. In less complicated
scenario it is just putting macro blocks of machine code together in
controlled fashion. The middle ground is to generate the machine code
in intermediate format where all symbols are named and register
allocator is the largest single task to overcome.

In both cases the implementation language is not as interesting as
what is done with it. The (1) has the goal to create solid quality
microcode for the GPU to execute and have good paths for data to go
through. The (2) has the same idea, but instead of microcode we
generate code for the CPU ALU instead, the data paths are less
sensitive to latency but more sensitive to cache as this path is more
flexible than the streaming model preferred for GPU.

If you are writing inner loops in HLL like C/C++ in that case again,
the C does not offer any real-world advantage over C if the programmer
understands his tools and knows how the HLL constructs map into
hardware instructions. This requires some experience with the compiler
and linker toolchain to have realistic expectations of the outcome of
HLL expressions. Usually at this level two things are done:

1. The results are measured against other alternatives
2. The output assembly (.s, .asm) is inspected so that there aren't
any surprises like calls to _ftol, or call to inline method and so on.
Inline keyword cannot be trusted in generic portable code to always
get the job done, sure, macros and other constructs can be used to
guide the code into the right direction.

The main thing is to measure, profile and check the output and adjust
the source code accordingly. It is a realistic expectation that the
compilers get better over time, not worse, so any optimization along
these guidelines will stay effective. On the other hand, some work-
arounds to get better output become obsolete over time and more
straightforward and descriptive expression usually slowly gains
ground.

All code written with this mindset is CONTEMPORARY and gets STALE over
time! VERY important to keep in mind.

This kind of micro-optimization is unnecessary for most programmers
for most of the time. Especially now that we have hardware to process
streamed data. For example, seems that what you are working on is a 2D
matrix of input that you map into output with 2D, finite-size kernel..
this kind of workload is often ideal for graphics processor to take a
peek at. The problem with this kind of thinking is the round-trip to
GPU local address space and back, if you can't synchronize the data
processing w/o flushing you're better off using the CPU most of the
time, where the technique (2) comes in.

What I'm getting at in roundabout way is that the C vs. C++ argument
is out-dated and even if that is the language of choice for the actual
inner loop, the C++ doesn't have ANY disadvantage except poor
programmers. The C is more hard-core and has less facilities to fuck
things up if you don't know how everything works. IN THAT SENSE it is
much better choice rather than let some sloppy C++ programmer try to
do a good job w/ tool he has no idea how to use properly. The key
concept is that this same sloppy C++ programmer might be TOP GUN C
programmer, so let him use the tools he knows best. But this is
totally different argument than that the C++ is inherently slow; it's
not.

[Ian Collins]

On 01/31/12 07:46 AM, 88888 Dihedral wrote:
>
> What I have emphasized is that C++ is better in a high level of controls
> of complex components organized as easy to use objects in a library or a package to be used by others, but it should not be
> used for heavy computing in the low level that needs to deal with hardware
> to avoid unnecessary overheads in repeated basic operations.

That problem only occurs if you don't know what you are doing. The C++
overheads are no greater than C overheads for the same operations.

--
Ian Collins

[Thomas Boell]

On Sat, 28 Jan 2012 16:37:36 -0000
"Paul" <pchrist<nospam>o...@yahoo.co.uk> wrote:

> A GUI designed for a touchscreen device will be alot different from a GUI
> designed for a PC with standard mouse/keyboard input.

http://hyperboleandahalf.blogspot.com/2010/04/alot-is-better-than-you-at-everything.html