The new examples for multiscreen purpose that you can see here :
webgl_multiple_canvases_circle
webgl_multiple_canvases_complex
webgl_multiple_canvases_grid
Are really cool, they even talk about the google Liquid galaxy project : liquidGalaxy
So, basically, I wonder how would I adapt the app in order to fit the need of multiple screen, lets say four 1920x1080 display, all displaying a nice part of the image.
I end up with a basic proof of concept, where I simply display new window screen content/canvas and sync the mouse position thru a node.js server and socket.io.
This works smoothly until I display window of different size.
See bellow the case where it fails.
For the record, please note that the full app is not working (the screen are not yet ready to be created on different computer), I'd like to first fix this offset issue.
thanks !
Oh, and if you want to try out or contribute, the project is here :
Screeny
Thanks again !
Ok, this was quiet logical, the windowHalfX value should be passed to each window. Now it works perfectly and code is updated. thanks for your remark !
The solution was to transfered with the mouseMove event the size of the current window and accordingly update all the window based on the window where movement happen.
Going deeper to make a fully working examples for separated computer.
Related
I am having trouble getting my GoJS Diagram to scale properly initially by setting the initialAutoScale property on the Diagram object as so:
myDiagram.initialAutoScale = go.Diagram.Uniform;
however, I AM able to set the fixed auto scale value like this, although it is not the behavior I want (does not allow ctrl-scroll zoom after initialization):
myDiagram.autoScale = go.Diagram.Uniform;
Admittedly, I am controlling and managing the GoJs Diagram from an Angular controller, which I understand is not the recommended way to use GoJS with Angular. That said, I am working with a short schedule on a web application that is much bigger than the piece I am currently working on and it is the best for the project if I CAN make it work within the controller construct.
Given that, I would love a recommendation for a fix, but also would very much appreciate any feedback regarding why autoScale might've worked while initialAutoScale doesn't, how initialAutoScale works and why in particular it might be angry with my Angular controller implementation, why else initialAutoScale wouldn't be happy, or any other ideas for a workaround.
I am happy to post more code as it is helpful. Thanks for any help!
Diagram.initialAutoScale determines the scale of the diagram after the Diagram.model has been replaced. So if you have set initialAutoScale: go.Diagram.Uniform, for example, then after you have replaced the Diagram.model with a new Model, the Diagram.scale will eventually be set so that the whole Diagram.documentBounds can be seen in the viewport.
If you do not replace the diagram's model, this property has no effect.
Setting Diagram.autoScale to go.Diagram.Uniform basically results in a call to Diagram.zoomToFit whenever there is a change to the document bounds or the viewport size or scale or scrollbar visibility or any other state which affects what is shown and where.
See http://gojs.net/latest/intro/initialView.html for more discussion.
Ran into a bit of an issue with a site I'm currently working on. It isn't breaking anything but I would like to create a better experience for my users. What I'm attempting to do is pertain the zoom levels of the mobile device on postback. To give better context, I have a calculator that needs to do a postback and every time it reloads the page, current zoom levels get reset to default. Sadly, the original site was built for desktops but many of our sales reps are using phones/tablets to access it. One plus to this however, is that all of them are supplied with android tablets. No need for apple support so if a solution would not work for an apple device it isn't a big deal.
I know that you can prevent page zooming using meta tags, but is there a way to make the zoom levels persist over postback? If there are any ways to handle this using javascript, html, or asp.net any help would be greatly appreciated.
Edit: Found a post here talking about detecting zoom levels. May be able to use this in a viewstate variable to reset zoom on postback. Will update if solution is found.
Thanks guys
Alright,
After a decent amount of searching, the only solution I have found seem to be a CSS zoom which I really would like to avoid. It doesn't look like you can actually modify zoom values at the browser level, which I can understand.
Link to one answer I found here.
I'm probably going to opt for using an IFrame or using mason's advice until I can get the entire site swapped over for mobile devices.
Thanks for the help guys!
Is there a way to turn debugging on or some command to show us rendering problems when using famo.us?
Log statements would be helpful or any other way of telling us what is going when the app is being rendered.
EDIT: Here are the rendering problems I have seen so far
1- Layout is inconsistent across browsers (Not even talking about IE yet!!!!).
Safari 7.02:
Chrome35:
Android Firefox 29:
2- Scrolling with famo.us is basically screwed.
I have 3 main sections my app (website):
Header (which is a ScrollContainer with 4 surfaces).
Footer (Which is a ScrollContainer with 1 surface).
Content (2 ScrollContainers on the left side and 2 ScrollContainers inside a Deck component on the right side. Each text/paragraph is a surface in its respective ScrollContainer).
Now, if you go to my app, you will notice that the scrolling is screwed and I have no idea why! I don't even know how I can debug this mess.
P.S: The code is left un-minified and with comments on purpose.
But wait there is more. Scrolling is confusing to the user as the user has no idea that this view is scrollable because no scrollbars are visible. You can even see that on the famo.us demo page. Go and try to scroll :). The only way you can scroll is if you go to the left side of the page ...
3- The Deck component seem to arrange the cards randomly on initial load based on the browser! As if things aren't already screwed enough. See screenshot below:
Chrome35 Desktop renders the green card first:
FF29 Desktop renders the red card first:
With all the above issues. I have no idea how to fix them or why they are happening.
List of things that will help me as a developer debug problems with famo.us:
Enable some debug logging when using components.
Throw JS errors when using components incorrectly.
Warn me about potential layout problems if using components with known issues.
Have better documentation. I basically read your code base to understand how to use something because the famo.us docs is not adding much value without having examples whereas your open source code does.
More articles talking about layout and page structure. This is a fundamental thing. If we can't get this right, there is no point playing with animations on a page that is not viewable correctly!
I have also noticed that FF29 on Desktop lags when I interact with the Deck of cards whereas on Chrome it doesn't. So backing up your 60fps claim across devices would be a good start. Show us performance metrics and comparisons to prove that claim.
I really want to use famo.us and I will hopefully contribute some fixes if I get some time but this is currently how I feel about famo.us.
Yes, it would be great if there was something that gave more info. Like a famoushint or something. I use jshint that at least helps with the common JavaScript errors.
Also, this has saved me a few times as well. http://famo.us/guides/pitfalls
But I agree it is a little buggy at this point, I've been having trouble with the Scrollview.
Currently there are no render specific debugging tools in Famo.us..
There are a couple of things I do when I run into problems..
1) Use javascripts 'debugger' command to stop the execution of the code and inspect the environment..
debugger;
2) Use a class that you can easily search in the surface you want to inspect. This class would contain no style but be unique enough to be used as an identifier to find the element quickly within the DOM tree.
var suspiciousSurface = new Surface({
size:[200,200],
classes: ['my-debug-class']
});
Hope this helps!
a famo.us app is fundamentally a javascript app, so the same techniques apply http://berzniz.com/post/78260747646/5-javascript-debugging-tips-youll-start-using-today
About the rendering, it is OK to inspect the DOM. If your scene is not too complex, you can quickly figure out which DIV your surfaces map to.
You can also outline a particular surface as #johntraver suggests, or also outline all the surfaces : in you CSS, add :
.famous-surface {
border: solid black 1px;
}
I made an application on processing which requires these information in order to make correct measurements;
horizontalScreenResolution
verticalScreenResolution
screenWidth
screenHight
I would like to use processingjs and include my sketch in web page. I already done that. However, this application gives correct results for particular screen. In order to solve this problem I want to create a form using html and java-script. User will enter its monitor parameters and whenever he clicks on start button sketch will be loaded according to given parameters and program will give correct results for every screen. However, is it possible to set this parameters before processinjs loads sketch to web page? Normally, it is possible to reach projessing parameters from javascript vice versa using processingjs.
I don't know how to do achieve this task.
Regards,
I would use displayWidth and displayHeight instead, these were added in Processing 2.0 (They replaced screen.width and screen.height). These are int values that tell you the size of the screen. So instead of asking every single person what their monitor parameters are. Just use these variables, should make your life much simpler I hope.
You can use
void setup(){
size(desiredWidth, desiredHeight);
}
to change the width and height of the canvas in pixels.
I do have a Paper.path() in Raphael that is filled with a simple texture:
var fill = screen.path(Iso.topFacePath(top)).attr({
fill: 'url(http://www.example.com/mytexture.jpg)',
});
The path can be altered by the user via drag and drop. For this I use Element.drag() to bind the handlers.
The problem that I encouter now is that while the onmove-handler function is called the element in question will be recalculated and has to be drawn again. Apparently this is "too much" for raphael and the fill pattern will disappear randomly (flicker) and appear again some time later (at latest onend).
The actual code I use is a little too much to post here but I built a fiddle where you can see what's going on (you can drag the upper sides of the quadrangle).
Is there a simple fix to this?
I am used to canvas much more than raphael (actually this is the first time I really use raphael) so maybe my approach of redrawing everything everytime sth changes is plain wrong?
EDIT: I just found out that seems to be somehow browser-related as well. Chrome and Firefox will produce the flicker where Safari seems to do everything just fine.
This seems to be caching issue (raphael.js does not cache the bitmap fill and will reload it on every change) and is fixed (for me) by this pull request on GitHub that is (as of 08/14/2012) still pending.
Raphael is pretty hard / impossible to build oneself as the make file points to local and/or inexistent files, but you can either concatenate everything by hand, modify the build script or use the modified build that is used in the example to get hold of the fix.
Let's hope it will find its way into a future release of Raphael.