be the solution for navit to work on our FRs [Om2008.9]?
Thanks,
--
sledge
--
View this message in context:
http://n2.nabble.com/Navit-patch-for-faster-map-dragging-tp729123p1328920.html
Sent from the Openmoko Community mailing list archive at Nabble.com
On Wednesday 17 September 2008, KaZeR wrote:
Thanks for your interest, i'm waiting for your lights on the font
part to commit it.
I profiled navit on my desktop using valgrind and a major part of the
time required for rendering the map is spent on rendering the fonts for
the street names, etc
@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
UP
--
View this message in context:
http://n2.nabble.com/Navit-patch-for-faster-map-dragging-tp729123p1106873.html
Sent from the Openmoko Community mailing list archive at Nabble.com
Hire a écrit :
Hello Florian Hackenberger, nice work, works very well.
However, do you have send those patch to navit's dev?
Hello,
I'm a member of the navit project. One of our users has told us about
this patch.
I've reviewed it, and it looks very good for the drag part. But i wasn't
On Tuesday 02 September 2008, Fox Mulder wrote:
Ok, i also meant the navit developer instead of OM.
I know that this problem doesn't exist with normal pc's but it also
doesn't harm normal pc's.
In fact it does, as there is the background is visible in areas where
there was no map drawn before
Is your patch surrently in the svn version integrated or do we still
need to patch the sourcecode with this?
If it is not integrated, wouldn't it be good to send this patch to the
author so he could integrate it?
I use debian on my neo and use the svn version to compile it myself
instead of
On Tuesday 02 September 2008, Fox Mulder wrote:
Is your patch surrently in the svn version integrated or do we still
need to patch the sourcecode with this?
It's up to the OM developers to integrate my patch, I do not have SVN
access. Could someone from OM please comment on that?
Cheers,
2008/9/2 Florian Hackenberger [EMAIL PROTECTED]:
It's up to the OM developers to integrate my patch, I do not have SVN
access. Could someone from OM please comment on that?
Surely it is up to the Navit developers to accept the patch, and I
don't suppose they read this mailing list...
Jeff
On Tuesday 02 September 2008, Jeffrey Ratcliffe wrote:
2008/9/2 Florian Hackenberger [EMAIL PROTECTED]:
It's up to the OM developers to integrate my patch, I do not have
SVN access. Could someone from OM please comment on that?
Surely it is up to the Navit developers to accept the patch, and
Charles-Henri Gros wrote:
Florian Hackenberger wrote:
One thing which still annoys me is the flicker while panning. I'm not
familiar with gtk and have not yet found a way to disable display
refreshes while doing a series of drawing operations. Any help is
welcome.
Ok, i also meant the navit developer instead of OM.
I know that this problem doesn't exist with normal pc's but it also
doesn't harm normal pc's. So i think it isn't a bad thing if you just
ask the navit developer if he/she integrates it into the source tree.
Until than i stick with version 1255
On Monday 18 August 2008, Charles-Henri Gros wrote:
gdk_window_begin_paint_region
gdk_window_end_paint
It's funny, I did the opposite of what you did while working on my
own version of tangoGPS, because I didn't like the white rectangles
around. I'm afraid that using that method will negate
Wahou !
That is way faster than before ! great !
So, I can view the maps, calculate the directions, but It does not
read gps data.
I am using FSO, and apparently there is no gpsd in the repositories.
The svn version you are using should have the gypsy patch, but I don't
see any vehicle_gypsy in
On Thursday 21 August 2008, Yohann (YC) Coppel wrote:
Wahou !
That is way faster than before ! great !
Thanks!
The svn version you are using should have the gypsy patch, but I
don't see any vehicle_gypsy in /usr/lib/navit/vehicle/. Is it
compiled it with some options (like --disable-gypsy) ?
Yohann (YC) Coppel wrote:
So, I can view the maps, calculate the directions, but It does not
read gps data.
I am using FSO, and apparently there is no gpsd in the repositories.
gpsd is installed in the GTA01 fso-testing image at shr.bearstech.com,
and navit is also in the fso-testing feeds. I
AhhhI feel so stupid...you must have meant 900MHz triband in terms of
network [:sheepish:]
On Fri, Aug 22, 2008 at 5:49 AM, Vikas Saurabh [EMAIL PROTECTED]wrote:
WHAT OM is shipping 900MHz version...at the same costmy v5 is still
working and I clearly remember it was 400MHz.
Would
Vikas Saurabh wrote:
WHAT OM is shipping 900MHz version...at the same costmy v5 is
still working and I clearly remember it was 400MHz.
That'd be the GSM radio frequency, not the CPU.
- Ben
___
Openmoko community mailing list
On Wed, 2008-08-20 at 13:04 +1000, Dale Maggee wrote:
so I tried:
[EMAIL PROTECTED]:/usr/share/navit# /etc/init.d/gpsd start
and got:
Starting gpsd: No GPS device, aborting gpsd startup. Check
/etc/default/gpsd
The line in /etc/default/gpsd needs to read (for freerunner):
Marcus Bauer wrote:
On Wed, 2008-08-20 at 13:04 +1000, Dale Maggee wrote:
so I tried:
[EMAIL PROTECTED]:/usr/share/navit# /etc/init.d/gpsd start
and got:
Starting gpsd: No GPS device, aborting gpsd startup. Check
/etc/default/gpsd
The line in /etc/default/gpsd needs to read
On Mon, Aug 18, 2008 at 12:36:18PM +1000, Dale Maggee wrote:
Subject: Re: Navit patch for faster map dragging
Florian Hackenberger wrote:
On Sunday 17 August 2008, Lothar Behrens wrote:
I had the same issue, but doing the same with -nodeps worked here
too.
Sorry, forgot
doing 'ls -R /usr/lib/navit/' gives me a list of all the libraries set
out in a directory structure, so the libraries are there... any Ideas
why it's not finding them?
quick idea: set LD_LIBRARY_PATH, but ...
1699 stat64(/usr/lib/navit/*/lib*.so, 0xbe9c0a78) = -1 ENOENT (No
these * look
On Tue, Aug 19, 2008 at 05:23:14PM +0200, arne anka wrote:
doing 'ls -R /usr/lib/navit/' gives me a list of all the libraries set
out in a directory structure, so the libraries are there... any Ideas
why it's not finding them?
quick idea: set LD_LIBRARY_PATH, but ...
1699
Am Dienstag 19 August 2008 17:39:56 schrieb Florian Lohoff:
On Tue, Aug 19, 2008 at 05:23:14PM +0200, arne anka wrote:
doing 'ls -R /usr/lib/navit/' gives me a list of all the libraries set
out in a directory structure, so the libraries are there... any Ideas
why it's not finding them?
On Tuesday 19 August 2008, Florian Lohoff wrote:
The problem is that the navit package contains only so.0.0.0 libs and
.so.0 symlinks - navit trys to open the libs with a simple .so
Broken package.
Hi!
Sorry, I forgot to add the navit.xml patch which was originally applied
to the navit 0.4.0
these * look odd. did you put them in there or are the really from
navit?
The problem is that the navit package contains only so.0.0.0 libs and .so.0
symlinks - navit trys to open the libs with a simple .so
Broken package.
Flo
changing navit.xml from
plugin
On Monday 18 August 2008, you wrote:
You should never set DEFAULT_PREFERENCE to -1 on an already working
recipe, just because you added a better svn recipe.
Thanks for pointing that out, I'm new to bitbake and found that to be
the only difference between the 0.0.4 and svn bitbake files and
Hi!
I'd like to submit a patch for navit, which changes the map dragging
rendering method for the gtk interface (which is used on the Neo).
Before the patch navit rerendered the map on each drag increment, which
was too slow on the neo. Now it simply repositions the rendered pixmap
and does
Am Sonntag 17 August 2008 12:22:45 schrieb Florian Hackenberger:
Hi!
I'd like to submit a patch for navit, which changes the map dragging
rendering method for the gtk interface (which is used on the Neo).
Before the patch navit rerendered the map on each drag increment, which
was too slow on
On Sunday 17 August 2008, Christian Anke wrote:
Nice work, with this the location search also works for me.
That's great, I haven't tried it yet, good to know. Where have you got
your maps from BTW?
* ERROR: Cannot satisfy the following dependencies for navit:
* gtk+ (= 2.12.11) *
On Sunday 17 August 2008 12:22:45 Florian Hackenberger wrote:
Hi!
I'd like to submit a patch for navit, which changes the map dragging
rendering method for the gtk interface (which is used on the Neo).
Before the patch navit rerendered the map on each drag increment, which
was too slow on
On Sunday 17 August 2008, Holger Freyther wrote:
Fantastic, did you consider sending the patch upstream?
I'll wait a few days. Usually I'm not satisfied with the first version
and keep improving it. I don't want to steal the time of the navit
developers by sending a stream of consecutive
PS: Please download the ipk using wget and then invoke opkg on the
downloaded file (instead of invoking opkg using the URL). There seems
to be a problem with opkg and the apache gzip compression.
Yeah, it gives the somewhat cryptic message: opkg: invalid magic
This is great, two of the
Am Montag, den 18.08.2008, 00:16 +1000 schrieb Dale Maggee:
PS: Please download the ipk using wget and then invoke opkg on the
downloaded file (instead of invoking opkg using the URL). There seems
to be a problem with opkg and the apache gzip compression.
Yeah, it gives the somewhat
On Sunday 17 August 2008, Lothar Behrens wrote:
I had the same issue, but doing the same with -nodeps worked here
too.
Sorry, forgot to mention that the ipk dependencies are a mess. You need
the -force-depends option (-nodeps is similar).
Great work :-)
Thanks!
But still an issue I see with
Hi !
Thanks for the patch !!!
On Sun, Aug 17, 2008 at 3:34 PM, Florian Hackenberger
[EMAIL PROTECTED] wrote:
One thing which still annoys me is the flicker while panning. I'm not
familiar with gtk and have not yet found a way to disable display
refreshes while doing a series of drawing
Am Sonntag, den 17.08.2008, 18:36 +0200 schrieb Florian Hackenberger:
But still an issue I see with big routes that are propably
recalculated at application startup. Consumes much CPU time and
partly blocks the UI.
I haven't got routing to work here with the OSM maps. It may be a
problem
Florian Hackenberger wrote:
On Sunday 17 August 2008, Lothar Behrens wrote:
I had the same issue, but doing the same with -nodeps worked here
too.
Sorry, forgot to mention that the ipk dependencies are a mess. You need
the -force-depends option (-nodeps is similar).
Great work :-)
Hi,
I have another idea that propably improves the 'speed'.
Why not prerender the other 8 rectangles of the screen that would then
have an effect to scroll in faster when the map is dragged in any
direction ?
In normal circumstances the user has to do with reading the map, thus
the CPU has time
diff --git a/packages/navit/navit_0.0.4.bb b/packages/navit/navit_0.0.4.bb
index 104495f..edd4519 100644
--- a/packages/navit/navit_0.0.4.bb
+++ b/packages/navit/navit_0.0.4.bb
@@ -4,4 +4,7 @@ PR = r0
SRC_URI = ${SOURCEFORGE_MIRROR}/navit/navit-${PV}.tar.gz
+DEFAULT_PREFERENCE = -1
+
Florian Hackenberger wrote:
On Sunday 17 August 2008, Holger Freyther wrote:
Fantastic, did you consider sending the patch upstream?
I'll wait a few days. Usually I'm not satisfied with the first version
and keep improving it. I don't want to steal the time of the navit
developers by
Florian Hackenberger wrote:
On Sunday 17 August 2008, Lothar Behrens wrote:
I had the same issue, but doing the same with -nodeps worked here
too.
Sorry, forgot to mention that the ipk dependencies are a mess. You need
the -force-depends option (-nodeps is similar).
Thanks, but
41 matches
Mail list logo
